bjam, mingw and cross-compiling

Hi, I find the bjam documentation and configuration files very frustrating... it seems to almost do what you want, but it doesn't finish the job and tell you how to actually do it correctly. I have been trying to cross-compile boost 1.35.0 for windows, on a linux host. The gcc.jam file mentions cross-compiling, but does not mention how to get it done. I almost got it to work with a user-config.jam: using gcc : mingw : /home/paul/mingw/bin/mingw32-g++ : <flavor>mingw32 <root>"/home/paul/mingwj/" ; and then hacking away at the gcc.jam file, which checks the os.system variable to decide how to link object files and use the -fPIC flag... around line 703: if [ os.on-windows ] change to... if [ modules.peek : UNIX ] to force it to use -mthreads instead of -pthreads if [ os.name ] != CYGWIN && [ os.name ] != NT change to if [ os.name ] = CYGWIN && [ os.name ] != NT to correct -fPIC it almost did the right thing, except for the extensions... i assume if i hack these lines, I'll get what i want... type.set-generated-target-suffix STATIC_LIB : <toolset>gcc <target-os>cygwin : a ; type.set-generated-target-suffix IMPORT_LIB : <toolset>gcc <target-os>cygwin : dll.a ; type.set-generated-target-prefix IMPORT_LIB : <toolset>gcc <target-os>cygwin : lib ; BUT then I'll have to fight to use the mingw32-ar and mingw32-windres and other programs. Isn't there an easier way? *please* I'm giving up on 1.35 as I've just read about the serialization vector bug, so I'll attempt to use 1.34.1 thanks, Paul

Hi Paul.
I'm giving up on 1.35 as I've just read about the serialization vector bug, so I'll attempt to use 1.34.1
If you're doing this then be sure to use the current trunk version of Boost Build or at least the version included with the Boost 1.35. release or you might run into 'already solved' build system issues. Best regards, Jurko Gospodnetić

2008/6/30 Jurko Gospodnetić
Hi Paul.
I'm giving up on 1.35 as I've just read about the serialization vector
bug, so I'll attempt to use 1.34.1
If you're doing this then be sure to use the current trunk version of Boost Build or at least the version included with the Boost 1.35. release or you might run into 'already solved' build system issues.
The problems described are from Boost 1.35 with bjam v2. I managed to wrangle 1.33.1's bjam v1 to cross-compile, but I could not figure out bjam v2. I think the key problem is that there seems to be no facility or option to cross-compile, to choose the target platform...

Paul wrote:
2008/6/30 Jurko Gospodnetić
mailto:jurko.gospodnetic@docte.hr>: Hi Paul.
I'm giving up on 1.35 as I've just read about the serialization vector bug, so I'll attempt to use 1.34.1
If you're doing this then be sure to use the current trunk version of Boost Build or at least the version included with the Boost 1.35. release or you might run into 'already solved' build system issues.
The problems described are from Boost 1.35 with bjam v2. I managed to wrangle 1.33.1's bjam v1 to cross-compile, but I could not figure out bjam v2.
I think the key problem is that there seems to be no facility or option to cross-compile, to choose the target platform...
The facility exists, but I'm not sure how well-developed it is at this point. I suggest posting about this problem on the boost-build list. -- Dave Abrahams BoostPro Computing http://www.boostpro.com

Paul wrote:
I think the key problem is that there seems to be no facility or option to cross-compile, to choose the target platform...
There is, it's called "target-os". http://svn.boost.org/trac/boost/browser/trunk/tools/build/v2/tools/builtin.j... -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org (msn) - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim,yahoo,skype,efnet,gmail

Hi Paul, Please see a previous post on this list: http://lists.boost.org/boost-users/2008/04/35614.php Rgds, Mikko Paul wrote:
Hi,
I find the bjam documentation and configuration files very frustrating... it seems to almost do what you want, but it doesn't finish the job and tell you how to actually do it correctly.
I have been trying to cross-compile boost 1.35.0 for windows, on a linux host. The gcc.jam file mentions cross-compiling, but does not mention how to get it done.
I almost got it to work with a user-config.jam: using gcc : mingw : /home/paul/mingw/bin/mingw32-g++ : <flavor>mingw32 <root>"/home/paul/mingwj/" ;
and then hacking away at the gcc.jam file, which checks the os.system variable to decide how to link object files and use the -fPIC flag...
around line 703: if [ os.on-windows ] change to... if [ modules.peek : UNIX ] to force it to use -mthreads instead of -pthreads
if [ os.name http://os.name ] != CYGWIN && [ os.name http://os.name ] != NT change to if [ os.name http://os.name ] = CYGWIN && [ os.name http://os.name ] != NT to correct -fPIC
it almost did the right thing, except for the extensions... i assume if i hack these lines, I'll get what i want...
type.set-generated-target-suffix STATIC_LIB : <toolset>gcc <target-os>cygwin : a ; type.set-generated-target-suffix IMPORT_LIB : <toolset>gcc <target-os>cygwin : dll.a ; type.set-generated-target-prefix IMPORT_LIB : <toolset>gcc <target-os>cygwin : lib ;
BUT then I'll have to fight to use the mingw32-ar and mingw32-windres and other programs.
Isn't there an easier way? *please*
I'm giving up on 1.35 as I've just read about the serialization vector bug, so I'll attempt to use 1.34.1
thanks, Paul
------------------------------------------------------------------------
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
--
:: Mikko Vainio

Hi Mikko,
I saw this post, it was useful to get me started in the right direction, but
it did not work because it wanted to use pthreads instead of mthreads.
using the -d+2 flag to see what was happening ...
"/home/paul/mingw/bin/mingw32-g++" -ftemplate-depth-128 -O3
-finline-functions -Wno-inline -Wall -pthread -DBOOST_ALL_NO_LIB=1
-DNDEBUG -I"." -c -o
"bin.v2/libs/test/build/gcc-mingw-3.4.5/release/link-static/threading-multi/unit_test_log.o"
"libs/test/src/unit_test_log.cpp"
mingw32-g++: unrecognized option `-pthread'
did you compile it on windows-mingw or linux-mingw ?
cheers
Paul
2008/6/30 Mikko Vainio
Hi Paul,
Please see a previous post on this list: http://lists.boost.org/boost-users/2008/04/35614.php
Rgds, Mikko
Paul wrote:
Hi,
I find the bjam documentation and configuration files very frustrating... it seems to almost do what you want, but it doesn't finish the job and tell you how to actually do it correctly.
I have been trying to cross-compile boost 1.35.0 for windows, on a linux host. The gcc.jam file mentions cross-compiling, but does not mention how to get it done.
I almost got it to work with a user-config.jam: using gcc : mingw : /home/paul/mingw/bin/mingw32-g++ : <flavor>mingw32 <root>"/home/paul/mingwj/" ;
and then hacking away at the gcc.jam file, which checks the os.system variable to decide how to link object files and use the -fPIC flag...
around line 703: if [ os.on-windows ] change to... if [ modules.peek : UNIX ] to force it to use -mthreads instead of -pthreads
if [ os.name http://os.name ] != CYGWIN && [ os.name http://os.name ] != NT change to if [ os.name http://os.name ] = CYGWIN && [ os.name http://os.name ] != NT to correct -fPIC
it almost did the right thing, except for the extensions... i assume if i hack these lines, I'll get what i want...
type.set-generated-target-suffix STATIC_LIB : <toolset>gcc <target-os>cygwin : a ; type.set-generated-target-suffix IMPORT_LIB : <toolset>gcc <target-os>cygwin : dll.a ; type.set-generated-target-prefix IMPORT_LIB : <toolset>gcc <target-os>cygwin : lib ;
BUT then I'll have to fight to use the mingw32-ar and mingw32-windres and other programs.
Isn't there an easier way? *please*
I'm giving up on 1.35 as I've just read about the serialization vector bug, so I'll attempt to use 1.34.1
thanks, Paul
------------------------------------------------------------------------
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
-- :: Mikko Vainio
tel + 358 2 215 4600 :: Structural Bioinformatics Laboratory :: Department of Biochemistry and Pharmacy :: Abo Akademi University, Tykistokatu 6A, FI-20520 Turku Finland _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

Paul, Indeed, cross-gcc nags about the -pthread option. I did not use the resulting libraries in multi-threaded code. In single-threaded they work. I compiled it on linux-mingw on Fedora 8. Rgds, Mikko Paul wrote:
Hi Mikko,
I saw this post, it was useful to get me started in the right direction, but it did not work because it wanted to use pthreads instead of mthreads. using the -d+2 flag to see what was happening ...
"/home/paul/mingw/bin/mingw32-g++" -ftemplate-depth-128 -O3 -finline-functions -Wno-inline -Wall -pthread -DBOOST_ALL_NO_LIB=1 -DNDEBUG -I"." -c -o "bin.v2/libs/test/build/gcc-mingw-3.4.5/release/link-static/threading-multi/unit_test_log.o" "libs/test/src/unit_test_log.cpp"
mingw32-g++: unrecognized option `-pthread'
did you compile it on windows-mingw or linux-mingw ?
cheers Paul
2008/6/30 Mikko Vainio
mailto:mivainio@abo.fi>: Hi Paul,
Please see a previous post on this list: http://lists.boost.org/boost-users/2008/04/35614.php
Rgds, Mikko
Paul wrote:
Hi,
I find the bjam documentation and configuration files very frustrating... it seems to almost do what you want, but it doesn't finish the job and tell you how to actually do it correctly.
I have been trying to cross-compile boost 1.35.0 for windows, on a linux host. The gcc.jam file mentions cross-compiling, but does not mention how to get it done.
I almost got it to work with a user-config.jam: using gcc : mingw : /home/paul/mingw/bin/mingw32-g++ : <flavor>mingw32 <root>"/home/paul/mingwj/" ;
and then hacking away at the gcc.jam file, which checks the os.system variable to decide how to link object files and use the -fPIC flag...
around line 703: if [ os.on-windows ] change to... if [ modules.peek : UNIX ] to force it to use -mthreads instead of -pthreads
if [ os.name http://os.name http://os.name ] != CYGWIN && [ os.name http://os.name http://os.name ] != NT change to if [ os.name http://os.name http://os.name ] = CYGWIN && [ os.name http://os.name http://os.name ] != NT to correct -fPIC
it almost did the right thing, except for the extensions... i assume if i hack these lines, I'll get what i want...
type.set-generated-target-suffix STATIC_LIB : <toolset>gcc <target-os>cygwin : a ; type.set-generated-target-suffix IMPORT_LIB : <toolset>gcc <target-os>cygwin : dll.a ; type.set-generated-target-prefix IMPORT_LIB : <toolset>gcc <target-os>cygwin : lib ;
BUT then I'll have to fight to use the mingw32-ar and mingw32-windres and other programs.
Isn't there an easier way? *please*
I'm giving up on 1.35 as I've just read about the serialization vector bug, so I'll attempt to use 1.34.1
thanks, Paul
------------------------------------------------------------------------
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org mailto:Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
-- :: Mikko Vainio
mailto:mikko.vainio@abo.fi> tel + 358 2 215 4600 :: Structural Bioinformatics Laboratory :: Department of Biochemistry and Pharmacy :: Abo Akademi University, Tykistokatu 6A, FI-20520 Turku Finland _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org mailto:Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
------------------------------------------------------------------------
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
--
:: Mikko Vainio

If you wanted too... you can also overload all the standard variables for
cross compilation and it "should" function properly.
// Rip'd from a script.
export CC=$(TARGET_STAGING_DIR)/bin/$(TARGET_ARCH)-linux-gcc
export CXX=$(TARGET_STAGING_DIR)/bin/$(TARGET_ARCH)-linux-c++
export AR=$(TARGET_STAGING_DIR)/bin/$(TARGET_ARCH)-linux-ar
export GCC=$(TARGET_STAGING_DIR)/bin/$(TARGET_ARCH)-linux-gcc
export GXX=$(TARGET_STAGING_DIR)/bin/$(TARGET_ARCH)-linux-g++
export LD=$(TARGET_STAGING_DIR)/bin/$(TARGET_ARCH)-linux-ld
export NM=$(TARGET_STAGING_DIR)/bin/$(TARGET_ARCH)-linux-nm
then call bjam install
I typically do this during cross compilation, as I don't trust most tools to
implicitly "do the right thing".
Instead, I explicitly configure an environment where there "can be only one"
way to compile.
Then I let the scripts sort it out...
Hope this helps,
Tim
On Mon, Jun 30, 2008 at 6:13 AM, Paul
Hi,
I find the bjam documentation and configuration files very frustrating... it seems to almost do what you want, but it doesn't finish the job and tell you how to actually do it correctly.
I have been trying to cross-compile boost 1.35.0 for windows, on a linux host. The gcc.jam file mentions cross-compiling, but does not mention how to get it done.
I almost got it to work with a user-config.jam: using gcc : mingw : /home/paul/mingw/bin/mingw32-g++ : <flavor>mingw32 <root>"/home/paul/mingwj/" ;
and then hacking away at the gcc.jam file, which checks the os.system variable to decide how to link object files and use the -fPIC flag...
around line 703: if [ os.on-windows ] change to... if [ modules.peek : UNIX ] to force it to use -mthreads instead of -pthreads
if [ os.name ] != CYGWIN && [ os.name ] != NT change to if [ os.name ] = CYGWIN && [ os.name ] != NT to correct -fPIC
it almost did the right thing, except for the extensions... i assume if i hack these lines, I'll get what i want...
type.set-generated-target-suffix STATIC_LIB : <toolset>gcc <target-os>cygwin : a ; type.set-generated-target-suffix IMPORT_LIB : <toolset>gcc <target-os>cygwin : dll.a ; type.set-generated-target-prefix IMPORT_LIB : <toolset>gcc <target-os>cygwin : lib ;
BUT then I'll have to fight to use the mingw32-ar and mingw32-windres and other programs.
Isn't there an easier way? *please*
I'm giving up on 1.35 as I've just read about the serialization vector bug, so I'll attempt to use 1.34.1
thanks, Paul
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
-- Regards, Timothy St. Clair [timothysc@gmail.com]

Hi Tim,
This probably won't work for the same reason highlighted in my reply to
Mikko - it will want to link to -pthreads instead of -mthreads, and do
various other things because it assumes that because the host computer is
linux, that I want to compile for linux.
ideas?
cheers,
Paul
2008/7/1 Tim St. Clair
If you wanted too... you can also overload all the standard variables for cross compilation and it "should" function properly.
// Rip'd from a script.
export CC=$(TARGET_STAGING_DIR)/bin/$(TARGET_ARCH)-linux-gcc
export CXX=$(TARGET_STAGING_DIR)/bin/$(TARGET_ARCH)-linux-c++ export AR=$(TARGET_STAGING_DIR)/bin/$(TARGET_ARCH)-linux-ar export GCC=$(TARGET_STAGING_DIR)/bin/$(TARGET_ARCH)-linux-gcc export GXX=$(TARGET_STAGING_DIR)/bin/$(TARGET_ARCH)-linux-g++
export LD=$(TARGET_STAGING_DIR)/bin/$(TARGET_ARCH)-linux-ld export NM=$(TARGET_STAGING_DIR)/bin/$(TARGET_ARCH)-linux-nm
then call bjam install
I typically do this during cross compilation, as I don't trust most tools to implicitly "do the right thing". Instead, I explicitly configure an environment where there "can be only one" way to compile.
Then I let the scripts sort it out...
Hope this helps, Tim
On Mon, Jun 30, 2008 at 6:13 AM, Paul
wrote: Hi,
I find the bjam documentation and configuration files very frustrating... it seems to almost do what you want, but it doesn't finish the job and tell you how to actually do it correctly.
I have been trying to cross-compile boost 1.35.0 for windows, on a linux host. The gcc.jam file mentions cross-compiling, but does not mention how to get it done.
I almost got it to work with a user-config.jam: using gcc : mingw : /home/paul/mingw/bin/mingw32-g++ : <flavor>mingw32 <root>"/home/paul/mingwj/" ;
and then hacking away at the gcc.jam file, which checks the os.system variable to decide how to link object files and use the -fPIC flag...
around line 703: if [ os.on-windows ] change to... if [ modules.peek : UNIX ] to force it to use -mthreads instead of -pthreads
if [ os.name ] != CYGWIN && [ os.name ] != NT change to if [ os.name ] = CYGWIN && [ os.name ] != NT to correct -fPIC
it almost did the right thing, except for the extensions... i assume if i hack these lines, I'll get what i want...
type.set-generated-target-suffix STATIC_LIB : <toolset>gcc <target-os>cygwin : a ; type.set-generated-target-suffix IMPORT_LIB : <toolset>gcc <target-os>cygwin : dll.a ; type.set-generated-target-prefix IMPORT_LIB : <toolset>gcc <target-os>cygwin : lib ;
BUT then I'll have to fight to use the mingw32-ar and mingw32-windres and other programs.
Isn't there an easier way? *please*
I'm giving up on 1.35 as I've just read about the serialization vector bug, so I'll attempt to use 1.34.1
thanks, Paul
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
-- Regards, Timothy St. Clair [timothysc@gmail.com] _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

I should probably elaborate a bit on this one, as I fall into the pArAnOiD
programming category. I usually create a chroot-env, or linux-kvm-env for
cross compilation to ensure it can *only* link what is available in that
env. I usually do this to ensure that my HOST env does not corrupt my
TARGET env is some strange way. (As you can probably tell I've been burnt
by this many times, so now I don't take any chances).
Or, you could setup a VMWare->Windows or linux Qemu-KVM ->Windows and build
your windows targets in a native env, but from a linux host.
Cheers,
Tim
On Tue, Jul 1, 2008 at 1:21 AM, Paul
Hi Tim,
This probably won't work for the same reason highlighted in my reply to Mikko - it will want to link to -pthreads instead of -mthreads, and do various other things because it assumes that because the host computer is linux, that I want to compile for linux.
ideas? cheers, Paul
2008/7/1 Tim St. Clair
: If you wanted too... you can also overload all the standard variables for
cross compilation and it "should" function properly.
// Rip'd from a script.
export CC=$(TARGET_STAGING_DIR)/bin/$(TARGET_ARCH)-linux-gcc
export CXX=$(TARGET_STAGING_DIR)/bin/$(TARGET_ARCH)-linux-c++ export AR=$(TARGET_STAGING_DIR)/bin/$(TARGET_ARCH)-linux-ar export GCC=$(TARGET_STAGING_DIR)/bin/$(TARGET_ARCH)-linux-gcc export GXX=$(TARGET_STAGING_DIR)/bin/$(TARGET_ARCH)-linux-g++
export LD=$(TARGET_STAGING_DIR)/bin/$(TARGET_ARCH)-linux-ld export NM=$(TARGET_STAGING_DIR)/bin/$(TARGET_ARCH)-linux-nm
then call bjam install
I typically do this during cross compilation, as I don't trust most tools to implicitly "do the right thing". Instead, I explicitly configure an environment where there "can be only one" way to compile.
Then I let the scripts sort it out...
Hope this helps, Tim
On Mon, Jun 30, 2008 at 6:13 AM, Paul
wrote: Hi,
I find the bjam documentation and configuration files very frustrating... it seems to almost do what you want, but it doesn't finish the job and tell you how to actually do it correctly.
I have been trying to cross-compile boost 1.35.0 for windows, on a linux host. The gcc.jam file mentions cross-compiling, but does not mention how to get it done.
I almost got it to work with a user-config.jam: using gcc : mingw : /home/paul/mingw/bin/mingw32-g++ : <flavor>mingw32 <root>"/home/paul/mingwj/" ;
and then hacking away at the gcc.jam file, which checks the os.system variable to decide how to link object files and use the -fPIC flag...
around line 703: if [ os.on-windows ] change to... if [ modules.peek : UNIX ] to force it to use -mthreads instead of -pthreads
if [ os.name ] != CYGWIN && [ os.name ] != NT change to if [ os.name ] = CYGWIN && [ os.name ] != NT to correct -fPIC
it almost did the right thing, except for the extensions... i assume if i hack these lines, I'll get what i want...
type.set-generated-target-suffix STATIC_LIB : <toolset>gcc <target-os>cygwin : a ; type.set-generated-target-suffix IMPORT_LIB : <toolset>gcc <target-os>cygwin : dll.a ; type.set-generated-target-prefix IMPORT_LIB : <toolset>gcc <target-os>cygwin : lib ;
BUT then I'll have to fight to use the mingw32-ar and mingw32-windres and other programs.
Isn't there an easier way? *please*
I'm giving up on 1.35 as I've just read about the serialization vector bug, so I'll attempt to use 1.34.1
thanks, Paul
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
-- Regards, Timothy St. Clair [timothysc@gmail.com] _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
-- Regards, Timothy St. Clair [timothysc@gmail.com]
participants (6)
-
David Abrahams
-
Jurko Gospodnetić
-
Mikko Vainio
-
Paul
-
Rene Rivera
-
Tim St. Clair