Re: [fluid-dev] compatibility version problem

[Pedro Lopez-Cabanillas]

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