Re: Adding SONAME to a shared object in KLEE
I don't know anything about this specific project, so I don't know
whether you're an upstream or downstream developer. In general SONAMEs
are something that should be managed upstream, to avoid incompatibility
between distributions. If your upstream rejects reasonable patches,
SONAMEs can be managed internally within Debian as a last resort;
but that would make binaries from Debian and not-Debian incompatible,
which is best avoided, and can also cause problems in future if upstream
later starts using SONAMEs correctly.
On Thu, 18 Feb 2016 at 22:58:48 +0100, Filippo Rusconi wrote:
> The library file proper should store a specific bit of information
> that is called a SONAME (shared object name). That SONAME should be in
> the form lib<name>.so.<major-version-number>. In our example, that would be
> libkleeRuntest.so.1 (as suggested by then file klee_1.1.0-1.dsc).
Please note that the version in the SONAME is not the "marketing version"
that you tell your users (or even your version control system), it's the
ABI version. The SONAME must change whenever the ABI changes incompatibly,
and should not change when the ABI remains compatible. If you're using
"semantic versioning", the version in the SONAME *might* match the
human-readable major version, but it also might not; if you're not using
semantic versioning, the version in the SONAME probably won't match the
major version.
For instance, choosing a couple of random libraries from my system:
- libappstream has broken ABI (several times?) before reaching version 1,
so its SONAME is libappstream.so.3 even though its version number is 0.9.1
- conversely, libassuan has never broken ABI, so its SONAME is libassuan.so.0
(meaning "compatible with the first ever version of libassuan.so") even
though its version number is 2.4.2
In some libraries you'll also see an "API version number" in the name
of the library itself. This is to allow for parallel-installation
of the *development files* for more than one version. For instance,
you can't have libjpeg 6b and libjpeg 8 installed at the same time,
because they both ship a libjpeg.so symlink; but you *can* have
Gtk 1, 2 and 3 development files at the same time, because their
libraries are called things like libgtk-3.so.0 (first ABI-version
for Gtk 3), with development symlink names like libgtk-3.so.
The classic document on this is <http://ometer.com/parallel.html>,
with an updated version recently made available at
<https://developer.gnome.org/programming-guidelines/unstable/parallel-installability.html.en>.
Parallel-installation is not at all GNOME-specific - it can also be
seen in Qt/KDE, SDL and DirectFB, for example - but it's very popular
in GNOME and GNOME-related projects, and those documents are the best
reference I've seen for how to do it and why.
S
Reply to: