Building boost with a non-default compiler?
Hi - I'm trying to build boost-1.35 on a Linux 2.4 machine where both gcc-2.95 (the default) and gcc-3.3 (the one I'd like to use) are installed, and I'm having a lot of problems. Perhaps you can help me figure out how to go forward? Attempt #1 -- use the configure script ======================================================================== To begin, I started by following the online instructions at http://www.boost.org/doc/libs/1_35_0/more/getting_started/unix-variants.html where it says (section 5.1) "Select your configuration options and invoke ./configure again...", so I selected the --with-toolset and --prefix options as follows: ------------------------------------ boost_1_35_0$ ./configure --with-toolset=gcc-3.3 --prefix=./BUILT Building Boost.Jam with toolset gcc-3.3... ./configure: ./bootstrap/jam0: No such file or directory tools/jam/src//bjam Detecting Python version... 2.2 Detecting Python root... /usr Unicode/ICU support for Boost.Regex?... not found. Generating Boost.Build configuration in user-config.jam... Generating Makefile... boost_1_35_0$ ------------------------------------ where I got the idea that the argument to --with-toolset should be gcc-3.3 from the description of toolsets in section 5.2.2 of the documentation which describes how to name toolsets for Boost.Build and states that If you have multiple versions of a particular compiler installed, you can append the version number to the toolset name, preceded by a hyphen, e.g. intel-9.0 or borland-5.4.3. Of course, trying to run the generated makefile fails miserably: ------------------------------------ boost_1_35_0$ make install ./tools/jam/src//bjam --user-config=user-config.jam --prefix=./BUILT --exec-prefix=./BUILT --libdir=./BUILT/lib --includedir=./BUILT/include install /bin/sh: ./tools/jam/src//bjam: No such file or directory Not all Boost libraries built properly. boost_1_35_0$ ------------------------------------ At this point I noticed that the documentation for section 5.2 states that "If you're using a compiler other than your system's default, you'll need to use Boost.Build to create binaries." Aha! Although it does leave me wondering what the --with-toolset option of the configure script is for... Attempt #2 -- Build Custom Binaries ======================================================================== For this attempt, I decided that I'd build everything from scratch. So I untarred a fresh source tree and began by building bjam, following the directions at http://www.boost.org/doc/libs/1_35_0/doc/html/jam/building.html ------------------------------------ $ cd tools/jam/src $ sh ./build.sh ------------------------------------ which build bjam cleanly using the gcc-2.95 default compiler. I then moved back to the root directory as described in section 5.2.4 of the documentation and invoked bjam as follows: ------------------------------------ $ export PATH=$BOOST_ROOT/tools/jam/src/bin.linuxx86:$PATH $ bjam --toolset=gcc-3.3 stage [...tons of stuff about compilation and failure messages...] ...failed updating 57 targets... ...skipped 52 targets... ...updated 188 targets... $ ------------------------------------ and while some of the libraries appear to have bee built, not all of them have been: ------------------------------------ $ find . -name libboost* ./stage/lib/libboost_signals-gcc33-mt-1_35.so ./stage/lib/libboost_regex-gcc33-mt.so ./stage/lib/libboost_regex-gcc33-mt-1_35.so ./stage/lib/libboost_prg_exec_monitor-gcc33-mt-1_35.so.1.35.0 ./stage/lib/libboost_prg_exec_monitor-gcc33-mt-1_35.so ./stage/lib/libboost_signals-gcc33-mt-1_35.so.1.35.0 ./stage/lib/libboost_signals-gcc33-mt.so ./stage/lib/libboost_prg_exec_monitor-gcc33-mt.so ./stage/lib/libboost_regex-gcc33-mt-1_35.so.1.35.0 ./bin.v2/libs/test/build/gcc-3.3/release/threading-multi/libboost_prg_exec_monitor-gcc33-mt-1_35.so.1.35.0 ./bin.v2/libs/regex/build/gcc-3.3/release/threading-multi/libboost_regex-gcc33-mt-1_35.so.1.35.0 ./bin.v2/libs/signals/build/gcc-3.3/release/threading-multi/libboost_signals-gcc33-mt-1_35.so.1.35.0 -------------------------------- which clearly shows that a wide variety of the libraries (such as boost_thread and boost_test) are missing. So the question is: do you have any suggestions about how I should proceed? I'm willing to capture all of the build output and look for failure messages to post here, but I thought I should show you what I did and see if there was anything glaringly wrong before I did that. Thanks! Dan
on Mon Jul 07 2008, Dan Katz <dakatz-AT-akamai.com> wrote:
Hi -
I'm trying to build boost-1.35 on a Linux 2.4 machine where both gcc-2.95 (the default) and gcc-3.3 (the one I'd like to use) are installed, and I'm having a lot of problems. Perhaps you can help me figure out how to go forward?
Attempt #1 -- use the configure script ======================================================================== To begin, I started by following the online instructions at
http://www.boost.org/doc/libs/1_35_0/more/getting_started/unix-variants.html
where it says (section 5.1) "Select your configuration options and invoke ./configure again...", so I selected the --with-toolset and --prefix options as follows:
------------------------------------ boost_1_35_0$ ./configure --with-toolset=gcc-3.3 --prefix=./BUILT
Looks good to me.
Building Boost.Jam with toolset gcc-3.3... ./configure: ./bootstrap/jam0: No such file or directory tools/jam/src//bjam
Urr. Looks like the procedure for building Boost.Jam is using a Boost.Build toolset name. They are distinct sets. Doug?
Detecting Python version... 2.2 Detecting Python root... /usr Unicode/ICU support for Boost.Regex?... not found. Generating Boost.Build configuration in user-config.jam... Generating Makefile... boost_1_35_0$ ------------------------------------
where I got the idea that the argument to --with-toolset should be gcc-3.3 from the description of toolsets in section 5.2.2 of the documentation which describes how to name toolsets for Boost.Build and states that
If you have multiple versions of a particular compiler installed, you can append the version number to the toolset name, preceded by a hyphen, e.g. intel-9.0 or borland-5.4.3.
You got the command right; there's a bug in the configure script. Try changing the line in ./configure that reads # Determine the toolset, if not already decided if test "x$TOOLSET" = x; then so that it reads: # Determine the toolset, if not already decided if test "x$TOOLSET" != y; then This is a hack, but it will build bjam with your system compiler no matter which toolset you've requested for your Boost build. That should be fine.
Of course, trying to run the generated makefile fails miserably:
------------------------------------ boost_1_35_0$ make install ./tools/jam/src//bjam --user-config=user-config.jam --prefix=./BUILT --exec-prefix=./BUILT --libdir=./BUILT/lib --includedir=./BUILT/include install /bin/sh: ./tools/jam/src//bjam: No such file or directory Not all Boost libraries built properly. boost_1_35_0$ ------------------------------------
Nothing wrong with the makefile other than that bjam didn't build. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
On 7 Jul 2008, dave@boostpro.com wrote:
boost_1_35_0$ ./configure --with-toolset=gcc-3.3 --prefix=./BUILT
Looks good to me.
Building Boost.Jam with toolset gcc-3.3... ./configure: ./bootstrap/jam0: No such file or directory tools/jam/src//bjam
Urr. Looks like the procedure for building Boost.Jam is using a Boost.Build toolset name. They are distinct sets. Doug?
[...]
You got the command right; there's a bug in the configure script.
Try changing the line in ./configure that reads
# Determine the toolset, if not already decided if test "x$TOOLSET" = x; then
so that it reads:
# Determine the toolset, if not already decided if test "x$TOOLSET" != y; then
This is a hack, but it will build bjam with your system compiler no matter which toolset you've requested for your Boost build. That should be fine.
So I made the change to the configure script that you suggested and then ran it. Things seemed to work okay at first but soon went awry: ------------------------------------ $ ./configure --with-toolset=gcc-3.3 --prefix=./BUILT Building Boost.Jam with toolset gcc... tools/jam/src/bin.linuxx86/bjam Detecting Python version... 2.2 Detecting Python root... /usr Unicode/ICU support for Boost.Regex?... not found. Backing up existing Boost.Build configuration in user-config.jam.1 Generating Boost.Build configuration in user-config.jam... Generating Makefile... $ make install [...lots of stuff...] ...skipped <pBUILT/lib>libboost_serialization-gcc295-mt.so for lack of <pBUILT/lib>libboost_serialization-gcc295-mt-1_35.so.1.35.0... ...skipped <pBUILT/lib>libboost_wserialization-gcc295-mt.so for lack of <pBUILT/lib>libboost_wserialization-gcc295-mt-1_35.so.1.35.0... common.hard-link BUILT/lib/libboost_signals-gcc295-mt.so common.hard-link BUILT/lib/libboost_prg_exec_monitor-gcc295-mt.so ...skipped <pBUILT/lib>libboost_test_exec_monitor-gcc295-mt.a for lack of <pBUILT/lib>libboost_test_exec_monitor-gcc295-mt-1_35.a... ...skipped <pBUILT/lib>libboost_unit_test_framework-gcc295-mt.so for lack of <pBUILT/lib>libboost_unit_test_framework-gcc295-mt-1_35.so.1.35.0... ...skipped <pBUILT/lib>libboost_thread-gcc295-mt.so for lack of <pBUILT/lib>libboost_thread-gcc295-mt-1_35.so.1.35.0... ...skipped <pBUILT/lib>libboost_wave-gcc295-mt.so for lack of <pBUILT/lib>libboost_wave-gcc295-mt-1_35.so.1.35.0... ...skipped <pBUILT/lib>libboost_date_time-gcc295-mt.so for lack of <pBUILT/lib>libboost_date_time-gcc295-mt-1_35.so.1.35.0... ...skipped <pBUILT/lib>libboost_system-gcc295-mt.so for lack of <pBUILT/lib>libboost_system-gcc295-mt-1_35.so.1.35.0... ...skipped <pBUILT/lib>libboost_filesystem-gcc295-mt.so for lack of <pBUILT/lib>libboost_filesystem-gcc295-mt-1_35.so.1.35.0... ...skipped <pBUILT/lib>libboost_graph-gcc295-mt.so for lack of <pBUILT/lib>libboost_graph-gcc295-mt-1_35.so.1.35.0... ...skipped <pBUILT/lib>libboost_iostreams-gcc295-mt.so for lack of <pBUILT/lib>libboost_iostreams-gcc295-mt-1_35.so.1.35.0... ...skipped <pBUILT/lib>libboost_program_options-gcc295-mt.so for lack of <pBUILT/lib>libboost_program_options-gcc295-mt-1_35.so.1.35.0... ...skipped <pBUILT/lib>libboost_python-gcc295-mt.so for lack of <pBUILT/lib>libboost_python-gcc295-mt-1_35.so.1.35.0... common.hard-link BUILT/lib/libboost_regex-gcc295-mt.so ...failed updating 57 targets... ...skipped 52 targets... ...updated 5741 targets... Not all Boost libraries built properly. ------------------------------------ And when I went to look in BUILT/lib, I didn't find many libraries and the ones I did find claimed that they were for gcc-2.95 (the default) rather than for the gcc-3.3 compiler I'd specified: ------------------------------------ $ ls BUILT/lib libboost_prg_exec_monitor-gcc295-mt-1_35.so libboost_prg_exec_monitor-gcc295-mt-1_35.so.1.35.0 libboost_prg_exec_monitor-gcc295-mt.so libboost_regex-gcc295-mt-1_35.so libboost_regex-gcc295-mt-1_35.so.1.35.0 libboost_regex-gcc295-mt.so libboost_signals-gcc295-mt-1_35.so libboost_signals-gcc295-mt-1_35.so.1.35.0 libboost_signals-gcc295-mt.so ------------------------------------ More issues in the configure script? Or is there something else I need to patch? Thanks! Dan
On 8 Jul 2008, dakatz@akamai.com wrote:
On 7 Jul 2008, dave@boostpro.com wrote:
boost_1_35_0$ ./configure --with-toolset=gcc-3.3 --prefix=./BUILT
Looks good to me.
Building Boost.Jam with toolset gcc-3.3... ./configure: ./bootstrap/jam0: No such file or directory tools/jam/src//bjam
Urr. Looks like the procedure for building Boost.Jam is using a Boost.Build toolset name. They are distinct sets. Doug?
[...]
You got the command right; there's a bug in the configure script.
Try changing the line in ./configure that reads
# Determine the toolset, if not already decided if test "x$TOOLSET" = x; then
so that it reads:
# Determine the toolset, if not already decided if test "x$TOOLSET" != y; then
This is a hack, but it will build bjam with your system compiler no matter which toolset you've requested for your Boost build. That should be fine.
So I made the change to the configure script that you suggested and then ran it. Things seemed to work okay at first but soon went awry:
------------------------------------ $ ./configure --with-toolset=gcc-3.3 --prefix=./BUILT Building Boost.Jam with toolset gcc... tools/jam/src/bin.linuxx86/bjam Detecting Python version... 2.2 Detecting Python root... /usr Unicode/ICU support for Boost.Regex?... not found. Backing up existing Boost.Build configuration in user-config.jam.1 Generating Boost.Build configuration in user-config.jam... Generating Makefile...
I took a look at the generated user-config.jam and found this: ------------------------------------ # Boost.Build Configuration # Automatically generated by Boost configure # Compiler configuration using gcc ; # Python configuration using python : 2.2 : /usr ; ------------------------------------ If I understand correctly, this means that boost will now be built with gcc (which is gcc-2.95) rather than the specified gcc-3.3. I imagine that I could fix this by going beyond the quick hack you described above and separating the toolsets for Boost.Jam and for Boost.Build in the configure script (perhaps introducing a TOOLSET_JAM variable or something). Is this the right way to go? Dan
Dan Katz wrote:
I took a look at the generated user-config.jam and found this:
------------------------------------ # Boost.Build Configuration # Automatically generated by Boost configure
# Compiler configuration using gcc ;
# Python configuration using python : 2.2 : /usr ; ------------------------------------
If I understand correctly, this means that boost will now be built with gcc (which is gcc-2.95) rather than the specified gcc-3.3.
I imagine that I could fix this by going beyond the quick hack you described above and separating the toolsets for Boost.Jam and for Boost.Build in the configure script (perhaps introducing a TOOLSET_JAM variable or something). Is this the right way to go?
It's the way I use a non-default compiler: # Compiler configuration using gcc : 3.4.4 : /opt/gcc344/bin/g++344 : <compileflags>-fPIC <linkflags>-fPIC ; You may not need the flags, but the version number and path to g++ are probably necessary. -- Dick Hadsell 914-259-6320 Fax: 914-259-6499 Reply-to: hadsell@blueskystudios.com Blue Sky Studios http://www.blueskystudios.com 44 South Broadway, White Plains, NY 10601
Richard Hadsell wrote:
Dan Katz wrote:
I took a look at the generated user-config.jam and found this:
------------------------------------ # Boost.Build Configuration # Automatically generated by Boost configure
# Compiler configuration using gcc ;
# Python configuration using python : 2.2 : /usr ; ------------------------------------
If I understand correctly, this means that boost will now be built with gcc (which is gcc-2.95) rather than the specified gcc-3.3.
I imagine that I could fix this by going beyond the quick hack you described above and separating the toolsets for Boost.Jam and for Boost.Build in the configure script (perhaps introducing a TOOLSET_JAM variable or something). Is this the right way to go?
It's the way I use a non-default compiler:
# Compiler configuration using gcc : 3.4.4 : /opt/gcc344/bin/g++344 : <compileflags>-fPIC <linkflags>-fPIC ;
You may not need the flags, but the version number and path to g++ are probably necessary.
Right, that's what you have to put to user-config.jam (either tools/build/v2/user-config.jam or ~/user-config.jam). Don't bother with configure, it falls short whenever you try to do anything non-standard. It's not apparent if all of Boost will build with any specific compiler version, if you see any compile error you'd have to examine those individually. - Volodya
On 9 Jul 2008, vladimir@codesourcery.com wrote:
Richard Hadsell wrote:
It's the way I use a non-default compiler:
# Compiler configuration using gcc : 3.4.4 : /opt/gcc344/bin/g++344 : <compileflags>-fPIC <linkflags>-fPIC ;
You may not need the flags, but the version number and path to g++ are probably necessary.
Right, that's what you have to put to user-config.jam (either tools/build/v2/user-config.jam or ~/user-config.jam). Don't bother with configure, it falls short whenever you try to do anything non-standard.
Great -- this approach worked for me. Thanks for the help! Dan
participants (4)
-
Dan Katz -
David Abrahams -
Richard Hadsell -
Vladimir Prus