Consider using SONAMEs for shared libraries #1774

Open
stapelberg opened this Issue Oct 8, 2016 · 1 comment

Projects

None yet

2 participants

@stapelberg
Contributor

(I’m describing the state based on FreeRADIUS 3.0.11, but I can’t find any indication of relevant changes in the 4.x branches, so I’m assuming it still holds true.)

Currently, the shipped shared libraries (libfreeradius-{eap,radius,server}.so) do not specify a SONAME:

root@854c44ac79bf# readelf -a /usr/lib/freeradius/libfreeradius-eap.so | grep SONAME
root@854c44ac79bf# readelf -a /usr/lib/libvirt.so.0 | grep SONAME
 0x000000000000000e (SONAME)             Library soname: [libvirt.so.0]

The Debian policy assumes that libraries use SONAME for versioning: https://www.debian.org/doc/debian-policy/ch-sharedlibs.html#s-sharedlibs-runtime

Aside from distribution-specific policy, I’d say there’s a general expectation in the open source community that shared libraries use SONAMEs for versioning.

I think this issue hasn’t surfaced earlier because there’s no package which actually depends on libfreeradius (at least in Debian at the time of writing). I’m assuming there’s users (e.g. in corporate environments) who would have an easier time if we were to use SONAMEs, though.

What do you think?

@alandekok
Member

Adding soname support is OK. It shouldn't be hard, as all of the "link library" code is concentrated in one place.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment