From: Glen Knowles (gknowles_at_[hidden])
Date: 2002-01-16 15:01:07
As the libtool folks say in the description of the problem, there are some
work arounds. KDE may have been willing to implement it for each of the
platforms that they support, I was not. The problem that manifest itself on
GNU/Solaris was that an exception thrown from within a shared object that
was not caught within that same shared object terminated the program.
> 1) KDE uses C++
> 2) KDE uses libtool
> 3) KDE has modules
> So libtool can't be that bad. Can it?
> We have had difficulty with libtool and C++, here is the description of
> 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++
> 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
> 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk