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
--
"Are you kidding me? We'd gather every Monday morning in the center of
the bridge, cry havoc, and let slip the rubbing of Patrick's head. We
always wanted to rub Shatner's bald head for luck, but he'd never take
off his toupee. So we'd just rub his belly instead." -- Wil Wheaton
Reply to: