Re: [boost] building shared boost libraries

From: Lee Brown (lee_at_[hidden])
Date: 2002-01-16 01:12:56

1) KDE uses C++
2) KDE uses libtool
3) KDE has modules

So libtool can't be that bad. Can it?

On Monday 14 January 2002 19:53, you wrote:
> 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/

----------------------------------------
Content-Type: text/html; charset="us-ascii"; name="Attachment: 1"
Content-Transfer-Encoding: 7bit
Content-Description: 
----------------------------------------