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

[Mats Wichmann]

On 6/20/19 1:56 AM, Christian Butcher wrote:
> 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://github.com/SCons/scons/wiki/ToolsForFools>
> 
> 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 

this all seems odd - you're calling bash to build things, which should
be fine for the Linux target, but for the Windows cases you'll be
building in a context where the platform looks like Linux, and scons, I
would guess, might get some things confused.  In my experience,
cross-building things with scons is non-trivial (more expert folks will
probably disagree with me here, it's just an opinion).

> 
> (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__).

as I think you've perhaps surmised, there's a list of builders and a
list of tools and they're synergistic - if a builder needs a tool, and
the tool is either omitted from the environment or doesn't initialize
because something is missing, then the builder that needs it will be
unavailable. leaving 'default' in the tool list should have kept the
SharedLibrary builder at least from vanishing.

If you dump the environment, what is in your list of BUILDERS?  You can
use the dict as you did, but env.Dump() formats a little prettier.

And what are your values for CC, CXX and SHLINK which are going to be
the most important bits?

> 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?

Perhaps a bit more debugging.  I wish scons had consistent logging so
you could tell it to record the decisions it makes as it initializes
tools, decides whether builders are usable, etc.  Some places have it
(the msvc tool uses the Python logging module as do a couple of other
places, but that's not carried out consistently across the codebase).

I don't know it's advisable to give up on SharedLibrary yet, maybe a
little bit more poking around is warranted.

How are you planning to tell the environment that it should prepend
'wsl' to the build lines?  I imagine you would modify the relevant *COM
variables - once we know if it's finding any at all.