Re: libtool, c++ and SO_names
On Friday 07 December 2001 16:40, Michael Banck wrote:
> Hello,
Hi!
> 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
use them.
> > 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
libname.
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
compiler.
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[1] so we would have some consistence in that field,
too.
uli
[1] 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.
Reply to: