need help configuring Boost for CodeSourcery ARM g++ compiler
I need to compile Boost for an embedded target running GNU/Linux on an ARM CPU. The toolchain for this is proprietary, compiler executable names are like "arm-none-linux-gnueabi-g++". I'm having trouble compiling with this toolchain though - I can't figure out (even with the documentation) what I'm doing wrong, but AFAICT Boost.Build keeps using my default gcc toolchain. In case it's relevant I'm on Cygwin using a self-compiled bjam executable, Boost is v1.34.1 My user-config.jam looks like this: <<<<<<<<<< # Compiler configuration # using gcc ; using gcc : : arm-none-linux-gnueabi-gcc ; using g++ : : arm-none-linux-gnueabi-g++ ; # Python configuration using python : 2.5 : /usr ;
>>>>
A dry run of the compilation with command: ./bjam --with-iostreams --with-regex --with-serialization --with-test --with-thread --toolset=gcc stage -n Produces a lot of output along these lines: <<<<<<<<<< Building Boost.Regex with the optional Unicode/ICU support disabled. Please refer to the Boost.Regex documentation for more information (don't panic: this is a strictly optional feature). ...patience... ...found 2215 targets... ...updating 977 targets... [--- snipped a load of 'MkDir1' lines ---] gcc.compile.c++ bin.v2/libs/serialization/build/gcc-3.4.4/release/threading-multi/basic_archive.o "g++" -ftemplate-depth-128 -O3 -finline-functions -Wno-inline -Wall -mthreads -DBOOST_ALL_NO_LIB=1 -DBOOST_SERIALIZATION_DYN_LINK=1 -DNDEBUG -I"." -c -o "bin.v2\libs\serialization\build\gcc-3.4.4\release\threading-multi\basic_archive.o" "libs\serialization\src\basic_archive.cpp"
>>>>
Why is it continuing to use "g++" when i've specified a different g++ executable to be used? Can anyone help me please? TIA, --rob
Rob Desbois wrote:
I need to compile Boost for an embedded target running GNU/Linux on an ARM CPU. The toolchain for this is proprietary, compiler executable names are like "arm-none-linux-gnueabi-g++".
I'm having trouble compiling with this toolchain though - I can't figure out (even with the documentation) what I'm doing wrong, but AFAICT Boost.Build keeps using my default gcc toolchain. In case it's relevant I'm on Cygwin using a self-compiled bjam executable, Boost is v1.34.1
My user-config.jam looks like this: <<<<<<<<<< # Compiler configuration # using gcc ; using gcc : : arm-none-linux-gnueabi-gcc ; using g++ : : arm-none-linux-gnueabi-g++ ;
[generally, boost.build questions are better asked a boost-build@lists.boost.org mailing list] Are you 100% sure you've placed user-config.jam in a location that Boost.Build looks in? You can use --debug-configuration option to print the location of user-config.jam that is actually loaded. Also, the above is not fully correct, per documentation you should have: using gcc : : arm-none-linux-gnueabi-g++ ; If you use: using g++ : ....... you should see an error, and if you don't see it it really means some other user-config.jam is loaded. - Volodya -- Vladimir Prus CodeSourcery
On Feb 6, 2008 12:07 PM, Vladimir Prus <ghost@cs.msu.su> wrote:
[generally, boost.build questions are better asked a boost-build@lists.boost.org mailing list]
Ok thanks for that. I guessed as my problem is with building boost with boost-build, not with the boost-build project itself, that it would be better here. If this is still off-topic and likely to annoy then please let me know and I'll take it there.
Are you 100% sure you've placed user-config.jam in a location that Boost.Build looks in? You can use --debug-configuration option to print the location of user-config.jam that is actually loaded.
Thanks - that was the problem. The documentation mentions user-config.jam, and there was one in my boost_1_34_1 folder so I assumed that was the one to use. It's a bit confusing having several around. I've found the one it was using and modified that instead.
Also, the above is not fully correct, per documentation you should have:
using gcc : : arm-none-linux-gnueabi-g++ ;
If you use:
using g++ : .......
you should see an error, and if you don't see it it really means some other user-config.jam is loaded.
Done. It's using the correct toolchain now, however won't compile. At the offset it passes an invalid option to `ld`, even if I let it run after that I get a horrendous number of compiler errors and lots of failure lines. I currently get this output: <<<<<<<<<< $ ./bjam.exe -q --with-iostreams --with-regex --with-test --with-thread stage Building Boost.Regex with the optional Unicode/ICU support disabled. Please refer to the Boost.Regex documentation for more information (don't panic: this is a strictly optional feature). ...patience... ...found 1395 targets... ...updating 364 targets... gcc.link.dll bin.v2/libs/regex/build/gcc-4.2.1/debug/boost_regex-gcc42-d-1_34_1.dll.a bin.v2/libs/regex/build/gcc-4.2.1/debug/boost_regex-gcc42-d-1_34_1.dll c:/program files/codesourcery/sourcery g++ lite/bin/../lib/gcc/arm-none-linux-gnueabi/4.2.1/../../../../arm-none-linux-gnueabi/bin/ld.exe: unrecognized option '--out-implib' c:/program files/codesourcery/sourcery g++ lite/bin/../lib/gcc/arm-none-linux-gnueabi/4.2.1/../../../../arm-none-linux-gnueabi/bin/ld.exe: use the --help option for usage information collect2: ld returned 1 exit status "arm-none-linux-gnueabi-g++.exe" "-Wl,--out-implib,bin.v2/libs/regex/build/gcc-4.2.1/debug/boost_regex-gcc42-d-1_34_1.dll.a" -o "bin.v 2/libs/regex/build/gcc-4.2.1/debug/boost_regex-gcc42-d-1_34_1.dll" -Wl,-h -Wl,boost_regex-gcc42-d-1_34_1.dll -shared -Wl,--start-group "bin.v2/libs/regex/build/gcc-4.2.1/debug/c_regex_traits.o" "bin.v2/libs/regex/build/gcc-4.2.1/debug/cpp_regex_traits.o" "bin.v2/libs/regex/build/ gcc-4.2.1/debug/cregex.o" "bin.v2/libs/regex/build/gcc-4.2.1/debug/fileiter.o" "bin.v2/libs/regex/build/gcc-4.2.1/debug/icu.o" "bin.v2/libs/regex/build/gcc-4.2.1/debug/instances.o" "bin.v2/libs/regex/build/gcc-4.2.1/debug/posix_api.o" "bin.v2/libs/regex/build/gcc-4.2.1/debug/regex.o" "bin.v2/libs/regex/build/gcc-4.2.1/debug/regex_debug.o" "bin.v2/libs/regex/build/gcc-4.2.1/debug/regex_raw_buffer.o" "bin.v2/libs/regex/build/gcc-4.2.1/debug/regex_traits_defaults.o" "bin.v2/libs/regex/build/gcc-4.2.1/debug/static_mutex.o" "bin.v2/libs/regex/build/gcc-4.2.1/debug/w32_regex_traits.o" "bin.v2/libs/regex/build/gcc-4.2.1/debug/wc_regex_traits.o" "bin.v2/libs/regex/build/gcc-4.2.1/debug/wide_posix_api.o" "bin.v2/libs/regex/build/gcc-4.2.1/debug/winstances.o" "bin.v2/libs/regex/build/gcc-4.2.1/debug/usinstances.o" -Wl,--end-group -g ...failed gcc.link.dll bin.v2/libs/regex/build/gcc-4.2.1/debug/boost_regex-gcc42-d-1_34_1.dll.a bin.v2/libs/regex/build/gcc-4.2.1/debug/boost_regex-gcc42-d-1_34_1.dll... ...failed updating 1 target...
>>>>
Are you able to help me with that? I'm hoping that this is the cause of the errors after it too, otherwise there's likely something horrible going on! Thanks, --rob
Rob Desbois wrote:
On Feb 6, 2008 12:07 PM, Vladimir Prus <ghost@cs.msu.su> wrote:
[generally, boost.build questions are better asked a boost-build@lists.boost.org mailing list]
Ok thanks for that. I guessed as my problem is with building boost with boost-build, not with the boost-build project itself, that it would be better here. If this is still off-topic and likely to annoy then please let me know and I'll take it there.
So far, nothing in this thread is specific to building Boost, as opposed to some other C++ library ;-) However, this time we can continue it here.
Are you 100% sure you've placed user-config.jam in a location that Boost.Build looks in? You can use --debug-configuration option to print the location of user-config.jam that is actually loaded.
Thanks - that was the problem. The documentation mentions user-config.jam, and there was one in my boost_1_34_1 folder so I assumed that was the one to use. It's a bit confusing having several around. I've found the one it was using and modified that instead.
Did you run configure? I think that's the only way a user-config.jam can be generated in the root folder. I'm meaning to raise the issue of 'configure' doing slightly confusing things on the devel list.
Also, the above is not fully correct, per documentation you should have:
using gcc : : arm-none-linux-gnueabi-g++ ;
If you use:
using g++ : .......
you should see an error, and if you don't see it it really means some other user-config.jam is loaded.
Done. It's using the correct toolchain now, however won't compile. At the offset it passes an invalid option to `ld`, even if I let it run after that I get a horrendous number of compiler errors and lots of failure lines. I currently get this output: ... gcc.link.dll bin.v2/libs/regex/build/gcc-4.2.1/debug/boost_regex-gcc42-d-1_34_1.dll.a bin.v2/libs/regex/build/gcc-4.2.1/debug/boost_regex-gcc42-d-1_34_1.dll c:/program files/codesourcery/sourcery g++ lite/bin/../lib/gcc/arm-none-linux-gnueabi/4.2.1/../../../../arm-none-linux-gnueabi/bin/ld.exe: unrecognized option '--out-implib'
I'm afraid this will require some manual work -- as presently, when running on windows, boost.build assumes you're targeting windows. For quick result, go to tools/build/v2/tools/gcc.jam and locate code fragment that goes like: if [ os.on-windows ] { .IMPLIB-COMMAND = "-Wl,--out-implib," ; ... } else { } Remove everything starting from "if" up until, and including, the "else". Let me know what errors, if any, remain after that. - Volodya -- Vladimir Prus CodeSourcery
On Feb 6, 2008 7:01 PM, Vladimir Prus <ghost@cs.msu.su> wrote:
Rob Desbois wrote:
On Feb 6, 2008 12:07 PM, Vladimir Prus <ghost@cs.msu.su> wrote:
[generally, boost.build questions are better asked a boost-build@lists.boost.org mailing list]
Ok thanks for that. I guessed as my problem is with building boost with boost-build, not with the boost-build project itself, that it would be better here. If this is still off-topic and likely to annoy then please let me know and I'll take it there.
So far, nothing in this thread is specific to building Boost, as opposed to some other C++ library ;-) However, this time we can continue it here.
Ok, thanks. I'm unfamiliar with Boost.Build so it's not easy to tell whether errors are caused by the build system or not!
Are you 100% sure you've placed user-config.jam in a location that Boost.Build looks in? You can use --debug-configuration option to print the location of user-config.jam that is actually loaded.
Thanks - that was the problem. The documentation mentions user-config.jam, and there was one in my boost_1_34_1 folder so I assumed that was the one to use. It's a bit confusing having several around. I've found the one it was using and modified that instead.
Did you run configure? I think that's the only way a user-config.jam can be generated in the root folder. I'm meaning to raise the issue of 'configure' doing slightly confusing things on the devel list.
I don't think so - I'm using the guide "Boost: Getting Started on Unix Variants" following 5.2 instead of 5.1 I've started on a freshly extracted archive to make sure.
Also, the above is not fully correct, per documentation you should have:
using gcc : : arm-none-linux-gnueabi-g++ ;
If you use:
using g++ : .......
you should see an error, and if you don't see it it really means some other user-config.jam is loaded.
Done. It's using the correct toolchain now, however won't compile. At the offset it passes an invalid option to `ld`, even if I let it run after that I get a horrendous number of compiler errors and lots of failure lines. I currently get this output: ... gcc.link.dll bin.v2/libs/regex/build/gcc-4.2.1/debug/boost_regex-gcc42-d-1_34_1.dll.a bin.v2/libs/regex/build/gcc-4.2.1/debug/boost_regex-gcc42-d-1_34_1.dll c:/program files/codesourcery/sourcery g++ lite/bin/../lib/gcc/arm-none-linux-gnueabi/4.2.1/../../../../arm-none-linux-gnueabi/bin/ld.exe: unrecognized option '--out-implib'
I'm afraid this will require some manual work -- as presently, when running on windows, boost.build assumes you're targeting windows. For quick result, go to
tools/build/v2/tools/gcc.jam
and locate code fragment that goes like:
if [ os.on-windows ] { .IMPLIB-COMMAND = "-Wl,--out-implib," ; ... } else { }
Remove everything starting from "if" up until, and including, the "else". Let me know what errors, if any, remain after that.
That solved the problem -- there was a similar section lower down the same file for which I commented out the [ os.on-windows ] code block: if [ os.on-windows ] { flags gcc OPTIONS <threading>multi : -mthreads ; } else if [ modules.peek : UNIX ] Thank you for your help :-) --rob
On Feb 6, 2008 7:01 PM, Vladimir Prus <ghost@cs.msu.su> wrote:
Rob Desbois wrote:
On Feb 6, 2008 12:07 PM, Vladimir Prus <ghost@cs.msu.su> wrote:
[generally, boost.build questions are better asked a boost-build@lists.boost.org mailing list]
Ok thanks for that. I guessed as my problem is with building boost with boost-build, not with the boost-build project itself, that it would be better here. If this is still off-topic and likely to annoy then please let me know and I'll take it there.
So far, nothing in this thread is specific to building Boost, as opposed to some other C++ library ;-) However, this time we can continue it here.
Ah, apologies - I'd missed the section in the Getting Started guide which instructs compiler-centric problems to be directed to the BB mailing list. Will be more careful now ;-) --rob
Rob Desbois wrote:
Are you able to help me with that? I'm hoping that this is the cause of the errors after it too, otherwise there's likely something horrible going on! Thanks,
Looks to me as if it thinks it's trying to build a Mingwin/Cygwin DLL, which isn't appropriate here: you could try a native cygwin build of bjam so it's not assuming it's building for Windows. Note that most Boost libraries can be treated as "just a bunch of sources" and built with whatever your favorite build tools are: in the case of Boost.Regex just build libs/regex/src/*.cpp into a shared or static library. There are also some sample makefiles in libs/regex/build that should be easy to customise if that helps. HTH, John.
Looks to me as if it thinks it's trying to build a Mingwin/Cygwin DLL, which isn't appropriate here: you could try a native cygwin build of bjam so it's not assuming it's building for Windows.
I'd built bjam myself under Cygwin with the default compiler.
Note that most Boost libraries can be treated as "just a bunch of sources" and built with whatever your favorite build tools are: in the case of Boost.Regex just build libs/regex/src/*.cpp into a shared or static library. There are also some sample makefiles in libs/regex/build that should be easy to customise if that helps.
Thanks, I've got a system built now - but I'll bear this in mind for the future. --rob
participants (3)
-
John Maddock -
Rob Desbois -
Vladimir Prus