[Boost-build] possible bug when cross compiling linux->windows

Subject: [Boost-build] possible bug when cross compiling linux->windows
From: Moritz Hassert (mhassert_at_[hidden])
Date: 2010-06-30 14:55:12

Hi,

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
'bjam --toolset=gcc-4.1'

But now I'm stuck with building on a linux host for a windows target:

Putting
'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 
mingw.

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.

Thanks
Moritz

Geschaeftsfuehrer: Dipl.-Inform. Christopher Asp
Amtsgericht Mannheim HRB 105845