Re: Best practices for shared C++ libs?
On Thu, 24 Jan 2002, Steve M. Robbins wrote:
> For C++ libraries, in contrast, the ABI can change just by changing
> the compiler. Some folks think that templates cause a problem, too
> (see below). How difficult is it to maintain binary compatibility
> with C++ libraries?
As with C, C++ code is binary compatible as long as the compilers use the
same ABI and no public interfaces change (extension of structs by private
data is allowed, but only on "final" [in Java terminology] classes). A
generic rule of thumb is that you are binary compatible if you didn't
change a header file.
> Should we bother trying, or just give up
> and embed the complete "major.minor.micro" version string into
> its SONAME?
What about going the middle road and using "major.minor" in the soname
(where major is the version of the UML diagram pinned onto the wall of the
lead programmer, minor is the number of releases with changed headers and
micro is the number of releases without changes to the headers)?
> Is libtool safe to use to build C++ libraries with Debian's
> compilers? The libtool manual has this to say about C++
> libraries:
It is as safe as the compilers you use.
[static initializers; libstdc++]
> The conclusion is that libtool is not ready for general use for C++
> libraries. You should avoid any global or static variable
> initializations that would cause an "initializer element is not
> constant" error if you compiled them with a standard C compiler.
libtool already calls $(CXX) for linking, so these two problems are worked
around. In general, you should not use static or global objects, or you
will run into trouble on platforms that do not properly support static
initializers.
> Furthermore, you'd better find out, at configure time, what are the
> C++ Standard libraries that the C++ compiler will link in by
> default, and explicitly list them in the link command line.
There are three approaches to deal with libstdc++ interface changes:
- Ignore the problem. This will lead to strange segfaults if someone
upgrades libstdc++ in an incompatible way and does not recompile your
library and all programs that link against it, but such incompatible
changes are seldom.
- Do what the libtool manual suggests, and explicitly link in the
standard C++ libraries. The linker should then bomb out if you try to
link a program compiled against the new libstdc++ with a library
compiled against the old version, however, not all linkers support
shared library dependencies yet (yhich is why libtool has them listed
in the .la file)
- Embed the version of libstdc++ your library was linked against into the
soname and link the library against libstdc++. This way, you get the
benefit of error reporting if you need to recompile your lib, and
binary compatibility for old programs (which will request a version
linked against old libstdc++ if they use that version themselves). Of
course, that compatibility will last only as long as the old libraries
are still around.
Look at the way the APT package handles this for libapt-pkg.
> Is #2 or #3 an issue with any of the compilers in Debian?
Not for gcc.
Simon
--
GPG public key available from http://phobos.fs.tum.de/pgp/Simon.Richter.asc
Fingerprint: DC26 EB8D 1F35 4F44 2934 7583 DBB6 F98D 9198 3292
Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread!
Reply to: