Building Boost 1.34.0 libraries with bjam
Options for building the Boost libraries with bjam seem to have changed from 1.33 to 1.34. At least, I can't be sure that the result will be the same. I looked at the 1.34.0 beta docs and the common.jam and gcc.jam files, but I am still unsure of what to do. I built the 1.33.x libraries this way: setenv PYTHON_VERSION 2.3 bjam -sTOOLS=gcc -sGCC_ROOT_DIRECTORY=/opt/gcc344 -sGXX="g++344 -m64" -sGCC="gcc344 -m64" --with-python-root=/usr --stagedir=stageFC3 -sBUILD="debug release <threading>multi <shared-linkable>true <instruction-set>opteron" stage Most of the options make it obvious what I want. The '<shared-linkable>true' option was necessary to add '-fPIC', which our binaries need in order to dynamically link (plug-in) shared libraries. I will appreciate any help you can offer in making the transition to 1.34.0 easier. BTW, it would be nice to see a list of available options for each toolset that comes with Boost bjam. -- 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:
I built the 1.33.x libraries this way:
setenv PYTHON_VERSION 2.3 bjam -sTOOLS=gcc -sGCC_ROOT_DIRECTORY=/opt/gcc344 -sGXX="g++344 -m64" -sGCC="gcc344 -m64" --with-python-root=/usr --stagedir=stageFC3 -sBUILD="debug release <threading>multi <shared-linkable>true <instruction-set>opteron" stage
I have made several attempts to persuade bjam to use /opt/gcc344/bin/g++344, and I finally discovered a solution for this part of the problem. I followed the Boost.Config doc the describes setting environment variables and running the configure script: setenv CXX /opt/gcc344/bin/g++344 setenv CXXFLAGS "-m64 -fPIC" setenv LDFLAGS "-m64 -fPIC" configure Then I looked at the resulting Makefile and user-config.jam. First, the environment variables seemed to have no effect on the user-config.jam. When I ran bjam afterward, it still used the default installed g++ on my system. So in user-config.jam I changed 'using gcc ;' to 'using gcc : 3.4.4 : /opt/gcc344/bin/g++344 ;'. (This was similar to a 'using' statement that I saw in a comment in tools/build/v2/user-config.jam.) Then I saw the '--user-config=user-config.jam' magic option in Makefile. I don't see this option documented in 'bjam --help' or anywhere else, but it worked. The bjam build messages are using 3.4.4 for the version part of the names, and the files are compiling. However, I doubt very much that the other options, especially '-fPIC', were picked up anywhere. I wouldn't want anyone to hold up the 1.34.0 release for these issues that are probably just documentation problems, but someone should note that it is difficult to figure out how to build with a g++ compiler other than the installed default one. And if I want to compile with other options (e.g., -m32 for 32-bit code), I don't think I can do it. I could still use help or, at least, reassurance. -- 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:
I wouldn't want anyone to hold up the 1.34.0 release for these issues that are probably just documentation problems, but someone should note that it is difficult to figure out how to build with a g++ compiler other than the installed default one. And if I want to compile with other options (e.g., -m32 for 32-bit code), I don't think I can do it.
I could still use help or, at least, reassurance.
Well the 32 vs. 64 option has been available for some time as an "address-model" feature when building. When not given the default for the compiler is used. For 1.33.1 (BBv1) to change it would mean adding "<address-model>64" for example, to the -sBUILD request. For 1.34.0 (BBv2) one would add an argument "address-model=64" when building. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo
Rene Rivera wrote:
Well the 32 vs. 64 option has been available for some time as an "address-model" feature when building. When not given the default for the compiler is used. For 1.33.1 (BBv1) to change it would mean adding "<address-model>64" for example, to the -sBUILD request. For 1.34.0 (BBv2) one would add an argument "address-model=64" when building.
Thanks. That helps. Do you know how to make sure I get "-fPIC" for all compilations (link-static as well as shared) with 1.34.0? -- 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:
Rene Rivera wrote:
Well the 32 vs. 64 option has been available for some time as an "address-model" feature when building. When not given the default for the compiler is used. For 1.33.1 (BBv1) to change it would mean adding "<address-model>64" for example, to the -sBUILD request. For 1.34.0 (BBv2) one would add an argument "address-model=64" when building.
Thanks. That helps.
Do you know how to make sure I get "-fPIC" for all compilations (link-static as well as shared) with 1.34.0?
I think: cxxflags=-fPIC - Volodya
Vladimir Prus wrote:
I think:
cxxflags=-fPIC
Thanks. I'll try it. -- 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
on Mon Apr 30 2007, Richard Hadsell <hadsell-AT-blueskystudios.com> wrote:
Richard Hadsell wrote:
I built the 1.33.x libraries this way:
setenv PYTHON_VERSION 2.3 bjam -sTOOLS=gcc -sGCC_ROOT_DIRECTORY=/opt/gcc344 -sGXX="g++344 -m64" -sGCC="gcc344 -m64" --with-python-root=/usr --stagedir=stageFC3 -sBUILD="debug release <threading>multi <shared-linkable>true <instruction-set>opteron" stage
I have made several attempts to persuade bjam to use /opt/gcc344/bin/g++344, and I finally discovered a solution for this part of the problem. I followed the Boost.Config doc
That won't help you. The ONLY thing that script does is set up some #defines that tell Boost about your compiler (mostly C++ standard conformance). John, people keep making this mistake; could you add a clarifying note to those docs? -- Dave Abrahams Boost Consulting http://www.boost-consulting.com Don't Miss BoostCon 2007! ==> http://www.boostcon.com
David Abrahams wrote:
That won't help you. The ONLY thing that script does is set up some #defines that tell Boost about your compiler (mostly C++ standard conformance). John, people keep making this mistake; could you add a clarifying note to those docs?
Done for CVS HEAD, should I patch the 1.34 release branch as well? John.
John Maddock wrote:
David Abrahams wrote:
That won't help you. The ONLY thing that script does is set up some #defines that tell Boost about your compiler (mostly C++ standard conformance). John, people keep making this mistake; could you add a clarifying note to those docs?
Done for CVS HEAD, should I patch the 1.34 release branch as well?
Pleas go ahead. Thomas -- Thomas Witt witt@acm.org
Thomas Witt wrote:
John Maddock wrote:
David Abrahams wrote:
That won't help you. The ONLY thing that script does is set up some #defines that tell Boost about your compiler (mostly C++ standard conformance). John, people keep making this mistake; could you add a clarifying note to those docs?
Done for CVS HEAD, should I patch the 1.34 release branch as well?
Pleas go ahead.
Now done, thanks, John.
Richard I have found the following to work for me. I have several versions of the compiler installed on my system for different projects. I also have several versions of python installed too. in my user-config.jam file in my home directory I have the following entries: using gcc : : /usr/local/gcc-4.1.2/bin/g++ : <linkflags>"-Wl,-rpath -Wl,/usr/local/gcc-4.1.2/lib" ; and using python : 2.5 : /usr/local/python-2.5.1_gcc-4.1.2 ; then I use the following command to build a version of boost. bjam --without-wave --without-test --prefix=<where to install to> --includedir=<where to put headers> --toolset=gcc stage NOTE: I am running on Linux. HTH Dave Riedel Richard Hadsell wrote:
Options for building the Boost libraries with bjam seem to have changed from 1.33 to 1.34. At least, I can't be sure that the result will be the same. I looked at the 1.34.0 beta docs and the common.jam and gcc.jam files, but I am still unsure of what to do.
I built the 1.33.x libraries this way:
setenv PYTHON_VERSION 2.3 bjam -sTOOLS=gcc -sGCC_ROOT_DIRECTORY=/opt/gcc344 -sGXX="g++344 -m64" -sGCC="gcc344 -m64" --with-python-root=/usr --stagedir=stageFC3 -sBUILD="debug release <threading>multi <shared-linkable>true <instruction-set>opteron" stage
Most of the options make it obvious what I want. The '<shared-linkable>true' option was necessary to add '-fPIC', which our binaries need in order to dynamically link (plug-in) shared libraries.
I will appreciate any help you can offer in making the transition to 1.34.0 easier.
BTW, it would be nice to see a list of available options for each toolset that comes with Boost bjam.
participants (1)
-
David Abrahams -
David P. Riedel -
John Maddock -
Rene Rivera -
Richard Hadsell -
Thomas Witt -
Vladimir Prus