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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
