Best practices for shared C++ libs?
Hello,
The Debian policy for shared libraries works well for C libraries.
In particular, one can generally tell if the library has retained
or broken binary compatibility so one knows whether to change the
SONAME (i.e. SONAME version) or not.
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? Should we bother trying, or just give up
and embed the complete "major.minor.micro" version string into
its SONAME?
Is libtool safe to use to build C++ libraries with Debian's
compilers? The libtool manual has this to say about C++
libraries:
-------------------- from libtool manual ---------------------
11.1 Writing libraries for C++
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.
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.
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.
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.
There are other ways of working around this problem, but they are
beyond the scope of this manual.
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.
Hopefully, in the future, libtool will be able to do this job by itself.
-----------------------------------------------------------------
Is #2 or #3 an issue with any of the compilers in Debian?
Here's a message about the Boost libraries. Remember that
John Maddock is concerned about binary compatibility
on many different platforms, not just Debian. However,
I'm curious whether this is an issue for Debian or not.
----- Forwarded message from John Maddock <John_Maddock@compuserve.com> -----
To: "INTERNET:boost@yahoogroups.com" <boost@yahoogroups.com>
From: John Maddock <John_Maddock@compuserve.com>
Mailing-List: list boost@yahoogroups.com; contact boost-owner@yahoogroups.com
Date: Sun, 20 Jan 2002 06:45:52 -0500
Subject: Re: [boost] building shared boost libraries
Reply-To: boost@yahoogroups.com
At the risk of throwing cold water all over the place, one reason that I've
always avoided version numbering shared libraries with the regex code is
that it's not at all clear to me that it's possible to maintain binary
compatibility in C++. In C it's pretty obvious if you do anything to break
binary compatibility, it's not clear to me what in C++ breaks compatibility
and what doesn't, particularly when the library contains template instances
*and* the compiler does link-time template instantiation. I would guess
that one would have to ensure that the library always contained the same
template instances - probably by doing explicit template instantiation - I
for one don't want to go into that level of detail. It is also apparent to
me that at least one commercial vendor of C++ libraries (Rogue Wave) never
assume that updated versions of their standard lib are binary compatible
with previous versions, I would be interested to know if anyone has ever
maintained binary compatibility with in C++ libraries as complex as boost.
So the question is, if binary compatibility is effectively impossible, what
do we do? Increment the major version number with every boost release?
Remember that even if I think that regex hasn't changed, something it
depends upon (shared pointer for eg) may have :-(
----- End forwarded message -----
-Steve
--
by Rocket to the Moon,
by Airplane to the Rocket,
by Taxi to the Airport,
by Frontdoor to the Taxi,
by throwing back the blanket and laying down the legs ...
- They Might Be Giants
Reply to: