libtool, c++ and SO-names
Hello,
I am still trying to package mpqc and it's library libsc. The last major
problem is with SO-names for the shared libraries. Upstream didn't use
SO-names yet, but is willing to do now. However, he said:
> The problem is that C++ is not binary compatible across different
> compiler vendors or even compiler versions. C++ optimizations end up
> coupling the private interface and public interface. Say libsc4_2.0.3
> was released and I only changed manual pages in 2.0.4. If I decided to
> switch from gcc 2.96 to gcc 3.0 in the 2.0.4 release, then I would have
> to release libsc5_2.0.4. Thus, to SO_NAME is coupled to both source and
> package issues.
and earlier:
> The problem with C++ is that it is very difficult to make any change
> without introducing binary incompatibilities due to possible changes
> in inline functions, virtual table layout, and data layout. Even
> building the new package with a newer version of the compiler or std
> library could cause problems. So, for example, 2.0.1 might be binary
> incompatible with 2.0.0, in fact, it probably would be incompatible.
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?
> 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?
thanks for any hints,
Michael
Reply to: