Consider using SONAMEs for shared libraries

[stapelberg]

(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]

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

[alandekok]

This still needs to be tested on other platforms, but I think that the code is now there in "master".

It could be back-ported to v3 without too much work.

[alarig]

Hi,

Do you know when it’s planned to be released? It triggers some warnings on Gentoo as well, see https://bugs.gentoo.org/721040

[hydrapolic]

Seems like it's disabled for Linux https://github.com/FreeRADIUS/freeradius-server/commit/1e471518da4ba3776a7de2cf589288f6e7977a33