Downstream .so name versioning
In case the upstream ships unversioned .so library (so this is not needed for plugins, drivers, etc.), the packager MUST try to convince upstream to start versioning it.
If it fails due to unwilling or unresposive upstream, the packager may start versioning downstream, but this must be done with caution and ideally only in rare cases, as the upstream version is the prefferd way. Under no cicumstances the unversioned library should be shipped in Fedora.
For downstream versioning, the name should be composed like this:
libfoobar.so.0.n
The n should be the number of downstream release. Do not forget to add the SONAME field (see below) to the library.
When new version of the library is released, you should use the
abi-compliance-checker
SONAME handling
When running an executable linked to shared object with SONAME field, the dynamic linker check for this field instead of filename to determine which object to link with. This allows developers to simply link against the unversioned library symlink and the dynamic linker will still links against the correct object.
Keep in mind that altough the SONAME and the filename should be the same, the
SONAME field actually matters when dynamically linking. The dynamic linker also
does only simple equality check on the field and do not check for ABI
incompatibilities and similar problems. This is the main reason for using the
The SONAME field is written to the shared object by linker, using (at least in
case of ld) the -soname SONAME flags. This could be
passed as option to both -Wl,-soname,SONAME flag. Example:
$ gcc $CFLAGS -Wl,-soname,libfoo.so.0.n -o libfoo.so.0.n
If you want to check if the SONAME field is set and what value it has, use the
objdump command (from
$ objdump -p /path/to/libfoo.so.0.n | grep 'SONAME'