Subject: [Boost-build] possible bug when cross compiling linux->windows
From: Moritz Hassert (mhassert_at_[hidden])
Date: 2010-06-30 14:55:12
first of all, I'd like to say thanks for this great build system!
I'm using boost-build here for a rather large project that is built both for
linux and windows, both 32 and 64 bit versions. It really makes live easier
being able to compile all the different versions within one source tree without
having to worry about build dirs.
Now I'm trying to make the next step and compile all those different targets on
my development box using cross compilers.
I'm using the latest nightly build and the latest bjam from svn.
I've managed so far to:
* compile 64bit linux binaries on a 32bit machine and vice versa by simply
installing a multilib version of gcc and doing a
'bjam address-model=64' or 'bjam address-model=32'
* use an older-than-default version of gcc by creating a user-config.jam in my
home dir containing
'using gcc : 4.1 : g++-4.1 ;'
and then doing
But now I'm stuck with building on a linux host for a windows target:
'using gcc : foo : /home/mhassert/bin/mingw-w64/bin/x86_64-w64-mingw32-g++ ;'
into user-config and then doing
'bjam --toolset=gcc-foo address-model=64 target-os=windows'
actually works perfectly.
But with the mingw line in user-config.jam normal building for linux is broken:
Just doing 'bjam' now builds into 'bin/gcc-mingw-4.4.3/...'
instead of 'bin/gcc-4.4.3/...'
It seems like the toolset flavor 'mingw' that is auto detected for the cross
compiler is somehow applied to all toolset versions, not only the actual
After digging into the boost-build sources, I assume that common.check-init-
parameters() in tools/common.jam is to blame:
Line 190 creates a new non-optional subfeature <flavor> of <toolset>gcc. This
subfeature is extended in line 195 with the value 'mingw'. To my understanding
of boost-build features this means that subfeature <flavor> now should have
'mingw' as its default value. And this default value is forced uppon all
toolset-versions without an explicit <flavor> definition.
* Adding 'optional' to line 190 seemed the obvious solution to me. However,
strange things happen:
toolset-commands are now empty strings, instead of
'gcc -Wall foo.cpp -c -o [...]/foo.o'
bjam -d+2 shows
'-Wall foo.cpp -c -o [...]/foo.o'
and of cause I get an '/bin/sh: -Wall: not found' error.
This happens for bjam --toolset=gcc and bjam --toolset=gcc-foo but not for
bjam --toolset=gcc-4.1 . Seems it fails when no explicit version is given or a
when a flavor is available?
* Then I tried something other:
I gave gcc-4.1 an explicit flavor like so:
'using gcc : 4.1 : g++-4.1 : <flavor>test ;'
I assumed this would prevent boost-build from assigning the default value. But
no luck: the build dir is still bin/gcc-mingw-4.1/... and again, the invoked
build command ist empty.
I'm pretty much out of ideas and bjam-knowledge now, so any help or hint would
be greatly appreciated.
Geschaeftsfuehrer: Dipl.-Inform. Christopher Asp
Amtsgericht Mannheim HRB 105845
Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk