[FFmpeg-devel] incorrect compatibility_version of libpostproc.dylib (libav*.dylib too?) on OS X

[Hanspeter Niederstrasser]

On 10/14/10 10:12 AM, Reinhard Tartler wrote:
> On Thu, Oct 14, 2010 at 15:18:12 (CEST), Hanspeter Niederstrasser wrote:
>
>> At some point between ffmpeg-0.4-20071217 and ffmpeg-0.5 (I know this
>> was a long time ago, but the issue persists through svn tip),
>> libpostprocess.dylib went from having a compatability_version of 51.1.0
>> to 51.0.0 (which is being set by libpostproc/postprocess.h).  On OS X,
>> this will break packages that used to link to old libpostprocess.dylib
>> because on OS X, the compat_version of the shared library is hardcoded
>> into the linking program, and so this appears as a downgrade and dyld
>> will complain.  postprocess.h indicates that LIBPOSTPROC_VERSION_MINOR
>> has been bumped to 2 for a while now, but this appears to not be being
>> used to set compat_version inside the shared library file.
>
> I don't follow here, can you please elaborate on what is exactly broken?
>  From reading your mail several times, it seems to me that you try to use
> an old libpostproc shared object with newer versions of other ffmpeg
> libraries. This is not supported and will just break.

Sorry I wasn't clear.  I'll give an example: xineplug_decode_ff.so from 
libxine is built against and links to "/sw/lib/libpostproc.dylib 
(compatibility version 51.1.0, current version 51.1.0)" among other 
libraries.  This libpostproc.dylib is from the old ffmpeg-0.4-20071217. 
  If I then update ffmpeg to 0.6, libpostproc.dylib is updated and 
changes to "compatibility version 51.0.0, current version 51.2.0".  So 
the compat_version has decreased for a dylib with the same install_name. 
  This then cause the loading of xineplug_decode_ff.so to fail because 
it expects libpostproc.dylib (51.1.0) but only has libpostproc.dylib 
(51.0.0) available.

Here's a simplified example: http://ffmpeg.pastebin.com/vPVKqw73

>> In fact, it looks like $LIBMAJOR is the only thing being used to set
>> compat_version on OS X (based on my reading of config.mak),
>
> Yes, and that is on purpose.

OK.  I can understand this, but at some point compat_version was being 
set by using all three version numbers, and dropping this caused 
compat_version to decrease, which makes dlopen unhappy.

>> but this is only currently affecting libpostproc.dylib because all the
>> other libav* have bumped their major version in the meantime (51.1.0<
>> 52.0.0).  Can a fix be done on libpostproc?
>
> To fix what exactly?

The fact that libpostproc.dylib's published compat_version has decreased 
but the install_name and file name have stayed the same.

>> Or would it be useful to add $LIBMINOR (or change to $LIBVERSION) to
>> the linker flags (SHFLAGS) in config.mak?  Or would this break future
>> updates going forward...?
>
> This would break pretty much.

I'm not suggesting this be the solution, but how would it break having 
compat_version go from $LIBMAJOR.0.0 as currently is, to 
$LIBMAJOR.$LIBMINOR.0?

Hanspeter