Boost logo

Boost Users :

From: David Abrahams (david.abrahams_at_[hidden])
Date: 2002-04-26 08:34:07


"John Maddock" <john_maddock_at_[hidden]> wrote in message
news:009501c1ed1a$a1df8ec0$1ec0193e_at_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
> > ...

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

> > MkDir1
> >
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<i
> > nt[]>':
> > 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


Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net