[LAU] [FFADO-devel] [ANN] FFADO 2.0 Release Candidate 1 (1.999.40) available

Jack O'Quin jack.oquin at gmail.com
Mon Nov 24 10:26:39 EST 2008

On Mon, Nov 24, 2008 at 8:35 AM, Jack O'Quin <jack.oquin at gmail.com> wrote:

> The traditional way is to use libtool version numbers.  The idea is to
> give the library a three-part number reflecting: (a) the current
> interface version; (b) minor compatible updates to that version; and
> (c) an indication of how many previous versions are also supported.
> It's basically a binary compatibility scheme.  The loader can compare
> the library version with that used by a program linking to it.  If the
> versions are compatible, then that library should work.  The idea is
> simple, but the details are quite messy and confusing...
>  http://www.nondot.org/sabre/Mirrored/libtool-2.1a/libtool_6.html
>  http://www.ensta.fr/~diam/dev/online/autoconf/autobook/autobook_91.html
> There is native support for all that in the automake, autoconf
> toolset, which leaves the question of how to do similar stuff in
> SCons.  I am just beginning to use SCons on another project, and
> coincidentally I wanted to do libtool versioning for it only last
> week.  I was unable to come up with a quick solution.  The native
> SCons SharedLibrary() method does not obviously support it.  I didn't
> spend much time researching the matter, however.
> SCons is a good tool, and is becoming popular.  Surely many people
> have already solved this problem by now.

A little further searching leads me to question that statement.  It
seems that SCons prefers not to use libtool, because it does not work
with Windows tools.


The suggestion about appending version numbers to the .so file name is
probably worth considering.  I'll give it some more thought.

I do think version numbers are going to be important for libffado,
given the need to coexist in the field with different versions of JACK
and other users of the library.

More information about the Linux-audio-user mailing list