Re: libtool, c++ and SO_names
On Friday 07 December 2001 16:40, Michael Banck wrote:
> The libtool-manual says about c++-libraries:
> > Creating libraries of C++ code should be a fairly straightforward
> > process, because its object files differ from C ones in only three
> > ways:
> > 1. 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.
> Does this mean I have to put a
> Depends: g++(= $MY_G++)
> into libsc-dev's depends?
Yes. And that is a point where you stung in a wesps nest. Already at the
current time, all C++ libraries in fact depend on the compiler they where
compiled with (or one that is binary compatible). At the moment we use a
system that implicitly uses g++2.9x as the C++-compiler. As far as that is
true, all is fine but as soon as someone wants to integrate a new one,
libraries will have to be compiled for the other compiler, too, in order to
> > 2. 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.
> Is Linux a 'some system'?
> > 3. 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.
> What does that mean?
> > The conclusion is that libtool is not ready for general use for C++
> > libraries.
> (Sorry for the longish quotes)
> So, can anybody point me to documentation on how to handle this, e.g.
> other c++-libraries who do it 'the right way'?
> Should I refrain from shipping (shared) libraries?
> What would happen if I change my c++-compiler but upstream doesn't?
> Would that mean that SO-names would be out of sync?
> Is everything easy and changing SO-names is really only needed for
> interface changes?
> If so, what does one have to consider?
I fear we need a general debian-wide plan for the transition to gcc-3, or
better, a general way to encode the target-compiler with the library. The
problem with the sonames is that those are maintained by upstream (usually)
but upstream is not responsible for the compiler we use. For C-libs, that
also means they are fully responsible for the binary interface, but for
C++-libs, they only control the interface on the source-level. Therefore,
sonames are not the proper solution in this case, even though they where
intended to provide a solution to an almost equal problem.
I think the point which has to be decided is whether we only need the 2.9x
and the 3.x-versions (btw: the gcc-people already gave warnings that 3.1 will
binary incompatible to 3.0, but 3.0 is not considered stable by them. ) If
we decide that we only need two C++compilers, we might get along with a hack,
eg using negative so-numbers for 3.x or putting a g++v3 somewhere in the
However, this solution is just an evil hack. The proper way would be to give
some means to categorize a library. That way, we would immediately see
whether a lib was created with g++ 2.9x, 3.0 or maybe a totally different
One hook we could use for that is a bitfield that says how far a compiler
resembles the cross-vendor standard http://www.codesourcery.com/cxx-abi/ .
Another hook we could use is that libtool already saves a configuration-file
( extension .la) which it uses to help linking. If that could be extended
with info that helps it choose the proper library for a given compiler, we
would have a more general solution.
Even more, modifying libtool would probably sooner or later also find its way
to other distributions so we would have some consistence in that field,
 what about the LSB (Linux standards base?), are they aware of those
problems ? Whatever we do, we should problably include them at least, but
possibly also the gcc-people and the libtool-people.