[FFmpeg-devel] incorrect compatibility_version of libpostproc.dylib (libav*.dylib too?) on OS X
Thu Oct 14 18:23:48 CEST 2010
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
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
More information about the ffmpeg-devel