Speex dev - Aug 2010 - speex-1.2rc1 breaks ABI on OS X

I'm currently working on packaging the latest version of speex for Fink, 
a Mac OS X package manager.  Our current speex version is at 1.1.6, and 
several new programs require a newer version, which is why I'm working 
on the update.

When 1.2b3 was released and some symbols were offloaded to 
libspeexdsp.1.dylib, this broke the library on OS X since 
libspeex.1.dylib kept the same install name but with a deficient ABI. 
Therefore any binary expecting to find these symbols in libspeex.1.dylib 
would fail with unresolved symbols after an upgrade.

Hanspeter

-- 
Hanspeter Niederstrasser
hanspeter at snaggledworks.com

The part of the ABI that changed was never actually frozen to begin with. The
stable part of the ABI (i.e. the codec part) is still the same as it was back
in 1.0.

    Jean-Marc

Quoting Hanspeter Niederstrasser <fink at snaggledworks.com>:
> I'm currently working on packaging the latest version of speex for
Fink,
> a Mac OS X package manager.  Our current speex version is at 1.1.6, and
> several new programs require a newer version, which is why I'm working
> on the update.
>
> When 1.2b3 was released and some symbols were offloaded to
> libspeexdsp.1.dylib, this broke the library on OS X since
> libspeex.1.dylib kept the same install name but with a deficient ABI.
> Therefore any binary expecting to find these symbols in libspeex.1.dylib
> would fail with unresolved symbols after an upgrade.
>
> Hanspeter
>
> --
> Hanspeter Niederstrasser
> hanspeter at snaggledworks.com
> _______________________________________________
> Speex-dev mailing list
> Speex-dev at xiph.org
> http://lists.xiph.org/mailman/listinfo/speex-dev
>
>

On 8/2/10 9:17 AM, Jean-Marc Valin wrote:
> The part of the ABI that changed was never actually frozen to begin with.
The
> stable part of the ABI (i.e. the codec part) is still the same as it was
back
> in 1.0.
>
>      Jean-Marc
Thanks for the reply.  The problem is that during compilation, Darwin's 
linker marks which linked library provides each symbol (determined by 
the install name) and at runtime, dyld only searches that library for 
that symbol.

So now, something that linked to the old prebeta3 libspeex.1.dylib and 
needs, for example _speex_echo_cancel, will fail when the new postbeta3 
libspeex.1.dylib is present.  It will not look for it in 
libspeexdsp.1.dylib.  So now, if one package was built against the old 
speex and a new package is built against the new speex, the new speex 
must first be placed into some random dir like $PREFIX/lib/speex-b3 to 
prevent a filename collision.

 From what I understand of libtool versioning, any time an interface is 
removed, the install name (Darwin's soname) needs to be bumped (via 
-version_info flag in Makefile.am, or updating CURRENT or some similar 
method) in order to maintain portability.  I now understand that the ABI 
for those things wasn't frozen, but those symbols were available and 
things could have linked against them, and now they're missing.

Hanspeter