Re: [Boost-users] Cross compiling boost libraries with gcc and using boost jam to crosscompile third-party library (Jambase problem)
Vladimir,
recently I was put into task to cross compile boost for ARM platform with GCC.
My building platform is i386 Linux with gcc and cross compiling to arm Linux.
I had the very same problem for my Coldfire cross-build (target "m68k-elf"), working under Windows XP using Cygwin. I didn't find a "standard way" of doing a cross-build of boost in its build documentation.
Standard way for this kind of compilation is, that name of cross compiler (running under i386 but producing arm code) and all cross binary utilities are prefixed by target plarform, so like arm-linux-gcc, arm-linux-g++, arm-linux-ar, arm-linux-objcopy for arm-linux.
This applies when using the GNU toolchain. But nowadays, most cross compilers are gcc based.
And this is causing a bit of problem with boost.
I can force GCC and GXX, but still have a problem with ar and objcopy.
I've tried to setup GCC_BIN_DIRECTORY but it didn't work.
I did basically the same thing to tools/build/v1/gcc-tools.jam as you did, at least with respect to ar and objcopy being available as variables that can be set on jam command line. I then used "-sGXX=m68k-elf-g++ -sGCC=m68k-elf-gcc -sAR=m68k-elf-ar" on my build command line. Additionally, I added support for selecting the CPU model (architecture/instruction-set) by adding the following: (I don't know how/why this works, just imitated the respective block for other architectures). Perhaps, boost build system should support (kind of) multilib builds for cross compilation, in a similar way that gcc/g++ does when cross-compiling it for targets where this applies? This enabled me to add "-sBUILD=debug release <runtime-link>static <optimization>size <architecture>m68k <instruction-set>5200" to the build command line for a Coldfire cross-build. It even somehow worked, as gcc got called with the correct -m option... # Coldfire and other m68k (WS, Tue Dec 20 16:46:10 2005). .ARCH = <architecture>m68k <architecture>native ; flags gcc CFLAGS <architecture>m68k/<instruction-set>default : -m5200 ; flags gcc CFLAGS <architecture>m68k/<instruction-set>68000 : -m68000 ; flags gcc CFLAGS <architecture>m68k/<instruction-set>5200 : -m5200 ; flags gcc CFLAGS <architecture>m68k/<instruction-set>5206e : -m5206e ; flags gcc CFLAGS <architecture>m68k/<instruction-set>528x : -m528x ; flags gcc CFLAGS <architecture>m68k/<instruction-set>5307 : -m5307 ; flags gcc CFLAGS <architecture>m68k/<instruction-set>5407 : -m5407 ; flags gcc CFLAGS <architecture>m68k/<instruction-set>cpu32 : -mcpu32 ; flags gcc CFLAGS <architecture>m68k/<instruction-set>68040 : -m68040 ; flags gcc CFLAGS <architecture>m68k/<instruction-set>68060 : -m68060 ; flags gcc CFLAGS <architecture>m68k/<instruction-set>soft-float : -msoft-float ;
So I've done a small patch to tools/build/v1/gcc-tools.jam adding GCC_PREFIX variable, that if set up, will prefix names of all tools with that prefix.
So I can compile boost with
bjam -sTOOLS=gcc -sGCC_PREFIX=arm-linux- stage
Ah, your approach with using GCC_PREFIX is even better! Perhaps call it "-sCROSS_TARGET=arm-linux" ?
May be it will be useful to add the same functionality to gcc-stlport-tools.jam or mingw.
So please find attached changes.
It is possible to include them into next boost release?
I strongly vote for integrating cross-compilation support (at least using GNU toolchain, after all that's what most use!) in the Boost build system. But I don't know or use jam or bjam (other than building (parts of) boost itself), so unfortunately I would be of little help... :-( I replied to the post becuase somone else might find the information helpful as well, I hope.
By the way, the same problem appears when boost jam is used to compile some third-party libraries. Is this place good to talk about boost jam and its Jambase file?
Probably move to the boost-build list? -wolfi -- DI Wolfram Stering (Entwicklung) HALE electronic GmbH., Salzburg, Austria Tel: +43 (662) 439011 550 Fax: +43 (662) 439011 9 Email: wolfram.stering@hale.at
Hi Stering, thank you for your ideas. As looking onto boost web pages, probably the list what you suggested boost-build is better to discuss this issue. Going to drop a message there. Vlad On Wed, 2006-01-11 at 08:36 +0100, Stering Wolfram wrote:
Vladimir,
recently I was put into task to cross compile boost for ARM platform with GCC.
My building platform is i386 Linux with gcc and cross compiling to arm Linux.
I had the very same problem for my Coldfire cross-build (target "m68k-elf"), working under Windows XP using Cygwin. I didn't find a "standard way" of doing a cross-build of boost in its build documentation.
Standard way for this kind of compilation is, that name of cross compiler (running under i386 but producing arm code) and all cross binary utilities are prefixed by target plarform, so like arm-linux-gcc, arm-linux-g++, arm-linux-ar, arm-linux-objcopy for arm-linux.
This applies when using the GNU toolchain. But nowadays, most cross compilers are gcc based.
And this is causing a bit of problem with boost.
I can force GCC and GXX, but still have a problem with ar and objcopy.
I've tried to setup GCC_BIN_DIRECTORY but it didn't work.
I did basically the same thing to tools/build/v1/gcc-tools.jam as you did, at least with respect to ar and objcopy being available as variables that can be set on jam command line. I then used "-sGXX=m68k-elf-g++ -sGCC=m68k-elf-gcc -sAR=m68k-elf-ar" on my build command line.
Additionally, I added support for selecting the CPU model (architecture/instruction-set) by adding the following: (I don't know how/why this works, just imitated the respective block for other architectures). Perhaps, boost build system should support (kind of) multilib builds for cross compilation, in a similar way that gcc/g++ does when cross-compiling it for targets where this applies?
This enabled me to add "-sBUILD=debug release <runtime-link>static <optimization>size <architecture>m68k <instruction-set>5200" to the build command line for a Coldfire cross-build. It even somehow worked, as gcc got called with the correct -m option...
# Coldfire and other m68k (WS, Tue Dec 20 16:46:10 2005). .ARCH = <architecture>m68k <architecture>native ; flags gcc CFLAGS <architecture>m68k/<instruction-set>default : -m5200 ; flags gcc CFLAGS <architecture>m68k/<instruction-set>68000 : -m68000 ; flags gcc CFLAGS <architecture>m68k/<instruction-set>5200 : -m5200 ; flags gcc CFLAGS <architecture>m68k/<instruction-set>5206e : -m5206e ; flags gcc CFLAGS <architecture>m68k/<instruction-set>528x : -m528x ; flags gcc CFLAGS <architecture>m68k/<instruction-set>5307 : -m5307 ; flags gcc CFLAGS <architecture>m68k/<instruction-set>5407 : -m5407 ; flags gcc CFLAGS <architecture>m68k/<instruction-set>cpu32 : -mcpu32 ; flags gcc CFLAGS <architecture>m68k/<instruction-set>68040 : -m68040 ; flags gcc CFLAGS <architecture>m68k/<instruction-set>68060 : -m68060 ; flags gcc CFLAGS <architecture>m68k/<instruction-set>soft-float : -msoft-float ;
So I've done a small patch to tools/build/v1/gcc-tools.jam adding GCC_PREFIX variable, that if set up, will prefix names of all tools with that prefix.
So I can compile boost with
bjam -sTOOLS=gcc -sGCC_PREFIX=arm-linux- stage
Ah, your approach with using GCC_PREFIX is even better! Perhaps call it "-sCROSS_TARGET=arm-linux" ?
May be it will be useful to add the same functionality to gcc-stlport-tools.jam or mingw.
So please find attached changes.
It is possible to include them into next boost release?
I strongly vote for integrating cross-compilation support (at least using GNU toolchain, after all that's what most use!) in the Boost build system. But I don't know or use jam or bjam (other than building (parts of) boost itself), so unfortunately I would be of little help... :-( I replied to the post becuase somone else might find the information helpful as well, I hope.
By the way, the same problem appears when boost jam is used to compile some third-party libraries. Is this place good to talk about boost jam and its Jambase file?
Probably move to the boost-build list?
-wolfi
--
Vladimir Michl
participants (2)
-
Stering Wolfram -
Vladimir Michl