On Tue, Oct 21, 2014 at 03:59:46PM +0100, David Howells wrote: > Is there a good description of ELF shared library symbol versioning best > practices somewhere? > > In particular, under what conditions do you need to create a new section in > the versioning file given to the linker's --version-script option when new > symbols are added? > > And what do you do if you've done it wrong? > > For example, in libkeyutils, I added a couple of symbols to KEYUTILS_1.4 when > I should perhaps have created KEYUTILS_1.5 and added them there: > > http://git.kernel.org/cgit/linux/kernel/git/dhowells/keyutils.git/commit/?id=49249ce7d84a967fcdc06fbe6bf1d0cf89ac5215 > > I have been given a patch to move these symbols to KEYUTILS_1.5, but checking > the keyctl program with "readelf -s", I see: > > 47: 0000000000000000 0 FUNC GLOBAL DEFAULT UND recursive_session_key_sca@KEYUTILS_1.4 (7) > > so I would guess applying this patch would break anything that uses this. > > I assumed that adding them to KEYUTILS_1.4 would be okay because nothing > would've tried to use them previously because they didn't exist in any > version. > > David Honestly, I don't think it matters, since the versions are all just arbitrary stings anyway. The fact that you added a symbol to an older version string rather than a new one isn't at all relevant to pre-existing binaries. And existing source code won't care about it if you happen to relink (as you note, older code won't use the new symbol anyway). The only real pain about it is that you need to keep it there now, since binaries linked against that version reference it as <symbol>@KEYUTILS_1.4. Irritating, maybe. Catastrophic, no. You certainly can do as libvirt does, and explicitly define the export list for every version, and there are some niceties to that, but its really not necessecary. IIRC, Glibc does exactly as you (meant to) do, in that new symbols are added into new version node piecemeal. Neil > -- > devel mailing list > devel@xxxxxxxxxxxxxxxxxxxxxxx > https://admin.fedoraproject.org/mailman/listinfo/devel > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
