What are the ELF shared lib symbol versioning best practices?

[Neil Horman]

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