From Fedora Project Wiki
(objdump example)
(Few clarifications)
Line 3: Line 3:
 
== Downstream .so name versioning ==
 
== 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.
+
In cases where 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.
+
If tjat 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.  We don't want to create a library that could conflict with upstream if they later start providing versioned shared libraries. Under no cicumstances should the unversioned library should be shipped in Fedora.
  
 
For downstream versioning, the name should be composed like this:
 
For downstream versioning, the name should be composed like this:
Line 11: Line 11:
 
libfoobar.so.0.n
 
libfoobar.so.0.n
 
</pre>
 
</pre>
The ''n'' should be the number of downstream release. Do not forget to add the SONAME field (see below) to the library.
+
The ''n'' should initially be a small integer (for instance, "1"). 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
+
When new versions of the library are released, you should use the
{{package|abi-compliance-checker}} tool to check differences in the build shared
+
{{package|abi-compliance-checker}} tool to check for differences in the build shared
libraries, and if it detects any incompatibilities, bump the ''n'' number
+
libraries, and if it detects any incompatibilities, bump the ''n'' number by one.
 
(reasons below).
 
(reasons below).
  

Revision as of 16:28, 3 April 2014


Downstream .so name versioning

In cases where 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 tjat 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. We don't want to create a library that could conflict with upstream if they later start providing versioned shared libraries. Under no cicumstances should 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 initially be a small integer (for instance, "1"). Do not forget to add the SONAME field (see below) to the library.

When new versions of the library are released, you should use the Package-x-generic-16.pngabi-compliance-checker tool to check for differences in the build shared libraries, and if it detects any incompatibilities, bump the n number by one. (reasons below).

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 Package-x-generic-16.pngabi-compliance-checker tool and the name bumping.

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 Package-x-generic-16.pnggcc and Package-x-generic-16.pnglibtool in the form of -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 Package-x-generic-16.pngbinutils):

$ objdump -p /path/to/libfoo.so.0.n | grep 'SONAME'