Boost logo

Boost :

From: Glen Knowles (gknowles_at_[hidden])
Date: 2002-01-14 21:53:13


We have had difficulty with libtool and C++, here is the description of the
problem from the libtool website http://www.gnu.org/software/libtool

--- cut here ---
Writing libraries for C++
Creating libraries of C++ code should be a fairly straightforward process,
because its object files differ from C ones in only three ways:

Because of name mangling, C++ libraries are only usable by the C++ compiler
that created them. This decision was made by the designers of C++ in order
to protect users from conflicting implementations of features such as
constructors, exception handling, and RTTI.
On some systems, the C++ compiler must take special actions for the dynamic
linker to run dynamic (i.e., run-time) initializers. This means that we
should not call ld directly to link such libraries, and we should use the
C++ compiler instead.
C++ compilers will link some Standard C++ library in by default, but libtool
does not know which are these libraries, so it cannot even run the
inter-library dependence analyzer to check how to link it in. Therefore,
running ld to link a C++ program or library is deemed to fail. However,
running the C++ compiler directly may lead to problems related with
inter-library dependencies.
The conclusion is that libtool is not ready for general use for C++
libraries. You should avoid any global or static variable initializations
that would cause an "initializer element is not constant" error if you
compiled them with a standard C compiler.

There are other ways of working around this problem, but they are beyond the
scope of this manual.

Furthermore, you'd better find out, at configure time, what are the C++
Standard libraries that the C++ compiler will link in by default, and
explicitly list them in the link command line. Hopefully, in the future,
libtool will be able to do this job by itself.

-----Original Message-----
From: David Abrahams [mailto:david.abrahams_at_[hidden]]
Sent: Monday, January 14, 2002 6:31 PM
To: boost_at_[hidden]
Subject: Re: [boost] building shared boost libraries

----- Original Message -----
From: "Timothy M. Shead" <tshead_at_[hidden]>

> > If it does everything so well, why do people use
> > other tools? I just want to get a balanced sense of its place in the
world.
>
> What other tools? I'd never heard of Jam until looking at the boost
> source a few days ago, and Jam doesn't provide near the functionality -

Oh, I realize Jam is a fringe case, but most developers I know are using a
mix of hand-tuned makefiles and shell scripts, or cons, or the like.

> it's fair to say that autoconf/automake/libtool is a complex solution to
> a complex problem; with an autotools-based build, I can do
>
> $ make distcheck
>
> and sit back while the tools create a distribution archive in one
> directory, unpack it into a second, cross-compile it into a third, and
> run regression tests on the results, leaving me with a very high level
> of confidence that the archive is complete and will compile for other
> people. If I give you that archive, you can do
>
> $ ./configure
> $ make distcheck
>
> and do the whole thing on your machine.

Boost.Build isn't targeted primarily at people who want to do a
configure/build/install in two keystrokes; it's primarily for developers who
need to go through the compile/edit/debug/test cycle on multiple compilers
with multiple configurations (e.g. debug, release, profiling, debug with
python memory debugging...), etc. We do believe that if we can do all of
that well, we will also be able to handle the installation problem with
little effort, but I think the target audience is really different

> Just about the only argument I
> can think of against using autotools for boost is that the average
> Windows installation doesn't have the environment necessary to run it.

Have you read our build system criteria?

http://www.boost.org/tools/build/build_system.htm#design_criteria

Are there still no reasons to use Boost.Build (and this part is important:)
from the point-of-view of the needs it's trying to satisfy?

Here's an extreme example handled by Boost.Build that should test how well
libtool satisfies some of our needs: If I want to create a project that
builds and tests python modules using KCC, GCC, and one other compiler all
at once on several platforms using libtool, how much work would it be?

-Dave

Info: http://www.boost.org Send unsubscribe requests to:
<mailto:boost-unsubscribe_at_[hidden]>

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/



Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk