[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [fluid-dev] compatibility version problem
From: |
Pedro Lopez-Cabanillas |
Subject: |
Re: [fluid-dev] compatibility version problem |
Date: |
Sun, 10 Oct 2010 10:11:40 +0200 |
User-agent: |
KMail/1.13.5 (Linux/2.6.34.7-0.3-desktop; KDE/4.4.4; i686; ; ) |
On Saturday 09 October 2010, James Le Cuirot wrote:
> On Fri, 8 Oct 2010 19:34:12 +0200
> "Pedro Lopez-Cabanillas" <address@hidden> wrote:
>
> > The autotools build system uses libtool, and these funny numbers are
> > a consequence of the libtool numbering scheme. The numbers are
> > absurd, BTW. What means the current version number "6.0.0"?
>
> I read this article today and thought of your comment above. You might
> find it interesting.
>
> http://blog.flameeyes.eu/2010/10/08/linkers-and-names
Both Linux and FreeBSD use the ELF format [1] for libraries and executables. I
didn't knew, and don't understand why, libtool doesn't follow the same
convention to create the SONAME in both platforms. On the other hand, Mac OSX
uses the MACH-O format [2] and there is not a SONAME attribute there, but
there is a "compatibility_version" attribute for the same purpose. Native
Windows dll/programs use the PE format [3], without any mechanism to specify
the ABI reference version, except appending it to the file name.
FluidSynth current releases are trying to be compatible (source and binary)
with the 1.0.0 interface. This means: any program compiled against
libfluidsynth 1.0.0 should work after upgrading the library to any version
named 1.2.x, 1.4.x, or 1.x.x (we are talking about the library version, not
the package version which follows a different numbering scheme). In Mac OSX
this goal has been defeated by the libtool/CMake differences, but not in
Linux, where both build systems produce compatible ABI version numbers. In
Linux/ELF, the library SONAME attribute can be seen with this command:
$ objdump -p /usr/lib/libfluidsynth.so
Dynamic Section:
SONAME libfluidsynth.so.1
[...]
Using the same command against a program linked to our library, the result is:
$ objdump -p /usr/bin/fluidsynth
Dynamic Section:
NEEDED libfluidsynth.so.1
[...]
The file name "libfluidsynth.so.1" is a symlink to the latest installed
library, for instance:
$ ls -l libfluidsynth*
libfluidsynth.so -> libfluidsynth.so.1
libfluidsynth.so.1 -> libfluidsynth.so.1.4.0
libfluidsynth.so.1.4.0
The first symlink "libfluidsynth.so" is only needed to build programs linked
to the library, and would be included in a "-devel" package. The second one is
the name matching the SONAME and NEEDED attributes, and it is the one required
by the dynamic loader at runtime. The third one is the real library file.
Some day in the future, we are going to publish a libfluidsynth-2.0.0 library
that will be incompatible with the 1.x.x series (because we can remove some
functions and change parameters in other functions). At this point, a Linux
user may have installed both the "libfluidsynth.so.1" and the new
"libfluidsynth.so.2" libraries at the same directory, and programs compiled
against both library versions may coexist in the same system at the same time
(but only one version for development: the headers and the "libfluidsynth.so"
symlink must belong to either the old, or the new one). I hope this helps to
explain why it is necessary an ABI version number, and how it is used in our
project, in addition to Diego's article.
Regards,
Pedro
[1] ELF
http://en.wikipedia.org/wiki/Executable_and_Linkable_Format
[2] MACH-O
http://en.wikipedia.org/wiki/Mach-O
[3] PE
http://en.wikipedia.org/wiki/Portable_Executable