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 -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
