[Scons-users] Windows Subsystem for Linux (WSL) with SCons for cross-compiling

[Jason Kenny]

Hi,

I use WSL a lot to test Linux builds myself. I find that it works best if you treat WSL as you would Cygwin. Install Scons and python as part of the wsl OS you are using and do the build. Trying to run a windows version of SCons and have it behave as it was running on Linux will cause a lot of pain. I believe that most of your error will go way if you do this.

Jason

From: Scons-users <scons-users-bounces at scons.org> On Behalf Of Christian Butcher
Sent: Thursday, June 20, 2019 2:56 AM
To: scons-users at scons.org
Subject: [Scons-users] Windows Subsystem for Linux (WSL) with SCons for cross-compiling

Dear Scons-Users List,

I'm currently using SCons to build a series of packages (on a Windows machine) using a tool that I've written based on the example here: ToolsForFools<https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FSCons%2Fscons%2Fwiki%2FToolsForFools&data=02%7C01%7C%7C072172d3a6c84bd5dc4508d6f554d465%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636966142022182843&sdata=QkikRTfwBqfTtAfd5eAGmgnyGphC45SxzzTn0naVres%3D&reserved=0>

I'm now trying to add compilation of a shared library (C++ code) that one of these packages depends on. I'd like to build using the Windows Subsystem for Linux to reduce necessary tools on my build machine (i.e. avoid MSVC + some tool for Linux compilation).

I have 3 target cases - Windows 32-bit, Windows 64-bit and Linux 32-bit, all as shared libraries (.dll, .dll, .so). The library depends on an existing 3rd-party library (thirdPartyLib32.dll, thirdPartyLib64.dll, libthirdParty32.so, currently all stored in the same directory within the source repository (git, not SCons)).

If I run directly from PowerShell, I can compile the library using command lines like the following:

W32
wsl i686-w64-mingw32-g++ -o test.dll Relative/Path\ With/Space/srcFileA.cpp Relative/Path\ With/Space/srcFileB.cpp  -shared -IRelative/Path\ To/Headers -D_WIN32 -DMYLIB_EXPORTS -fvisibility=hidden -O3 -L Relative/Path\ To/3rdPartyLib -lthirdPartyLib32

W64
wsl x86_64-w64-mingw32-g++ -o test.dll Relative/Path\ With/Space/srcFileA.cpp Relative/Path\ With/Space/srcFileB.cpp  -shared -IRelative/Path\ To/Headers -D_WIN32 -DMYLIB_EXPORTS -fvisibility=hidden -O3 -L Relative/Path\ To/3rdPartyLib -lthirdPartyLib64

Linux32
wsl g++ -o test.so  Relative/Path\ With/Space/srcFileA.cpp Relative/Path\ With/Space/srcFileB.cpp -shared -IRelative/Path\ To/Headers -D_WIN32  -DLINUX_BUILD_MODE -DMYLIB_EXPORTS -fvisibility=hidden -O3 -L Relative/Path\ To/3rdPartyLib -lthirdPartyLib32 -fPIC -m32 -Wno-attributes

(although the -Wno-attributes is probably a) irrelevant to this discussion, and b) a sign that I need to work on my macro for the Linux compilation...)

I suspect that doing this with an Action might be fairly simple, but would perhaps lose the ability to check for source changes unless I also use a Depends call.

If I use SharedLibrary, I keep getting an error that SConsEnvironment object has no attribute 'SharedLibrary'. I understand this is due to my overwriting the 'tools' input to the Environment constructor, but using tools = ['default', 'myTool'] doesn't help.
Why is this? Which values need to be written (and can these be written after the initialization of the Environment?). I've tried setting things like env['SHCXX'] and env['CXX'] but this produces no visible change (at least to the error - the changes are visible when printing env.__dict__).

What is the correct/best/most SCons-like way to do this? Should I be setting the 'platform' value when creating the Environment (and would I need to write a new platform object?)? Should I avoid the SharedLibrary builder and use Action + Depends or similar?

Best regards,
Christian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist4.pair.net/pipermail/scons-users/attachments/20190620/ba41e500/attachment-0001.html>