BerkeleyDB 6 symbol versioning and associated problems

[Adam Jackson]

On Wed, 2014-05-07 at 15:19 +0200, Jan Staněk wrote:
> One of the planned parts of the F21 System Wide Change: BerkeleyDB 6 [1]
> is the introduction of downstream symbol versioning of both versions of
> the libraries (libdb with v6 and libdb5 with v5). This part is planned
> in order to not introduce bugs similar to [2]. However, if we introduce
> downstream versioning (as upstream is generally unresponsive), then we
> face the problem similar to [3].
> 
> In short, if we introduce the downstream versioning, we will ship
> library with ABI incompatible with upstream ABI. If we won't,
> applications with modules/plugins (ie. Apache with mod_perl) that each
> use different version of the library may break due to double symbols
> (one from the v5 and other from v6, and ld would not know which symbol
> is which).
> 
> I'd like to ask for suggestions on how to resolve this problem.

It's unfortunate that BerkeleyDB doesn't use a system like pkg-config,
where the name of the library being linked is disconnected from the
module being requested; if it were, we could build a libfeddb-6.so with
symbol versioning and a libdb-6.so without, link our OS with the former
by simply switching what the pkgconfig file points to, and maintain a
semblance of binary compatibility with the outside world.

It's also unfortunate that symbol versioning falls over like this.  The
relevant section from Uli's writeup reads:

---
[... I]f the object with the references uses symbol versions but the
object with the definitions has none.  In this case a matching symbol is
accepted unless the object's name matches the one in the Elfxx_Verneed
entry.  In the latter case this is a fatal error.  In fact, this should
never have happened in the first place since it would mean the list of
required symbols was not correct and the steps required in the last
section therefore haven't detected a too old version of an object file.
---

This sort of breaks the upgrade path from unversioned to versioned
symbols within a library, if I understand it correctly; adding versions
effectively requires bumping the object's soname, since otherwise
linking against libfoo.so.1 just after versions were added would prevent
that binary from running against an unversioned-but-otherwise-identical
libfoo.so.1.  (Unless the library still exports unversioned names for
every symbol, I suppose.)

Which is doubly unfortunate, since it means ld can't just decide to
enable --default-symver at some point, as every binary linked afterwards
will be incompatible with prior runtimes.

I don't know if I have a good suggestion here, none of the alternatives
sound appealing.

- ajax