"John Maddock" wrote in message news:009501c1ed1a$a1df8ec0$1ec0193e@1016031671...

...

I'm just trying to install Boost library under RedHat 7.2. I was following the build instructions found on the Boost website, but it seemed to fail for several targets.

The first thing to realise is that most of boost does not require you to build anything (just use the headers), those parts that do require building (currently the thread, regex, and python libs), can be built pretty easily without using the jam build system if you would rather - just build libs/foo/src/*.cpp into an archive in order to build lib "foo".

Uhh, I disagree when it comes to the Python lib. The build is not exactly trivial.

...

I'm wondering if it's because RH7.2 uses its version of gcc 2.96.

That's part of your problem. 2.96 is not an official GCC release, and no 2.9x version seems to work properly with Boost.Python v1.

...

Since my project work needs gcc 3.0+, my question is, what do I need to do in order to use gcc3/g++3 instead of gcc/g++? The build system seems exotic and I just want to get over with the installation asap and start to use the library.

Just set the GCC_ROOT_DIRECTORY variable to point at the root of your gcc-3.0.x installation. I am using jam -sGCC_ROOT_DIRECTORY=/usr/local -sBOOST_ROOT=<boost-root> -sTOOLS=gcc Of course you can also export an environment variable if you don't want to stick it on your jam command-line.

...

(does changing /usr/bin/gcc and /usr/bin/g++ links work?)

Here is the build command I tried:

jam -sBOOST_ROOT=. -sTOOLS="gcc"

The build command is fine, though you may need to configure some additional stuff.

...

Errors (selected):

... libs/thread/build/../src/once.cpp: In function `void boost::call_once (void (*) (), once_flag &)': boost/thread/once.hpp:38: previous declaration of `void boost::call_once (void (*) (), once_flag &)' with C++ linkage libs/thread/build/../src/once.cpp:77: conflicts with new declaration ...

...

MkDir1

If I remember correctly, this was a bug in the released version of the threads library. It certainly doesn't have anything to do with the build system. I suggest using the latest version of boost from the CVS, where the bug has been fixed libs/python/build/bin/libboost_python_static/gcc/debug/runtime-link-dynam

...

ic/shared-linkable-true gcc-C++-action libs/python/build/bin/libboost_python_static/gcc/debug/runtime-li nk-dynamic/shared-linkable-true/types.o In file included from boost/python/errors.hpp:13, from boost/python/detail/call_object.hpp:8, from libs/python/build/../src/types.cpp:11: boost/python/detail/wrap_python.hpp:24:24: patchlevel.h: No such file or directo ry boost/python/detail/wrap_python.hpp:100:20: Python.h: No such file or directory ...

This is a configuration issue; the build system can't find your Python installation. Again I'd suggest using the latest version of Boost from the CVS. One reason is that the build system is now much smarter about detecting your Python installation (or the lack thereof) and giving help about how to configure it. It will tell you which variables to set in order to point the build at the desired version of Python. You can force it to do that by typing: jam -flibs/python/build/__init__.py from the boost root directory. Another reason to use the CVS is that the CVS version of Boost.Python works much more-reliably with a wider range of compilers (2.9x isn't one of them, though).

...

(lots of Python-related errors) ... gcc-C++-action status/bin/is_function_test/gcc/debug/runtime-link-dynamic/is_fun ction_test.o boost/type_traits/function_traits.hpp: In instantiation of `boost::is_function': status/../libs/type_traits/tests/is_function_test.cpp:68: instantiated from he re boost/type_traits/function_traits.hpp:148: Internal error: Segmentation fault. Please submit a full bug report. See URL:http://bugzilla.redhat.com/bugzilla/ for instructions. ...

Any internal compiler error is a bug in the compiler, which may explain why gcc-2.96 is not considered an official release ;-) HTH, Dave