[Scons-users] How to handle cross-compilation on Windows
Ted Middleton
tmiddleton at teradici.com
Tue Aug 28 19:35:08 EDT 2012
I have a build system that handles builds on Linux, OSX, and Windows. Some of the builds are for embedded, and for reasons that I won't go into, they use a cross-compiling version of gcc on Windows. When I create an environment on Windows, it seems like scons wants to implicitly use the msvc tool
env = Environment() # actually just the same as env = Environment( tools = ['msvc'] )
To get past this we specified the gnu tools explicitly in the Environment creation - that seems to suppress the 'msvc' tool. Or at least it mostly suppresses it.
env = Environment( tools = ['gcc', 'g++', 'ar', 'as', 'gnulink'] )
Mind you I'm not actually using a standard version of gcc - later on I have to set env['CC'] to arm-none-gnulinux-gcc with the correct path, but at least this keeps scons from using '/switch' rather than '-switch' in the compiler commands.
This mostly solves the problem, but it's a bit clunky. I'm finding that it's also leaky - it seems that maybe the 'msvc' tool is still running but then perhaps being stomped on by the gnu tools that I'm specifying. For example, I was diagnosing why scons was having a difficult time finding a dependency on a shared library that we're building. It turned out that scons, when determining the LIBS and LIBPATH dependencies, was rifling through the LIBPATH looking for 'libfoobar.lib' and completely ignoring the possibility that there might be a 'libfoobar.so'. Obviously this is the right thing to do with the 'msvc' tool, but not with a gcc cross-compiler.
Am I doing this wrong? Is there a clean way of telling scons to stop using the 'msvc' tool and instead use the gnu tools on Windows?
More information about the Scons-users
mailing list