Re: Symbol-versioning a C++ library
* Bas Wijnen:
> This is slightly off-topic, for which I apologise. It's just that I
> learned about symbol versioning during my NM process, and nobody outside
> Debian seems to understand what it is. :-(
*sigh* It's a bit sad that this is still being used in the NM process.
> I have a library, which I want to package for Debian. I felt it would
> be a good idea to use symbol versioning, since most of my programs (and
> in some cases other libraries) use it. The library is written in C++,
> which seems to be a slight problem. AFAIU the linker should be able to
> handle it, but I don't see how. Let's start with the problem in more
> detail:
Before you do this, you should check if symbol versioning buys you
anything in your case. If an application uses libA and libB which
both depend on libC, but in two different versions libC1 and libC2,
and you want to pass a libC-implemented object from libA to libB or
vice versa, this still does not work. If libA and libB completely
hide their dependency on libC, you won't run into such problems.
And there's also problem which is rather C++-specific: When an object
is created, the size of the object is typically compiled into the
creator, unversioned. This means that unless the API is very
carefully designed, you end up with non-versioned dependencies anyway.
The poster child for symbol versioning, GNU libc, uses one source
version to provide multiple, versioned entry points. This offers
complete control over the interplay of versions, and works best for C
code. Symbol versioning is no magic bullet that lets you escape DLL
hell. In general, what saves us is the ability to recompile large
parts of our software archive against new library versions, not symbol
versioning.
Reply to: