[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: libtool, c++ and SO_names

On Friday 07 December 2001 16:40, Michael Banck wrote:
> Hello,

> 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 
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[1] so we would have some consistence in that field, 


[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: