Uoti Urpala <uoti.urpala at pp1.inet.fi> writes:
> On Tue, 2009-12-01 at 21:42 +0100, Reinhard Tartler wrote:
>> so yes, the application ('FFmpeg' in this case) tries to resolve the
>> symbols that have been versioned as FFMPEG_0.5 at compilation time. It
>> fails to resolve them, because the libraries that didn't change SONAME
>> have been replaced with current FFmpeg trunk.
>>>> Did I misunderstand symbol versioning (again)? Are my versioning scripts
>> wrong?
>> You shouldn't change the symbol version if the SONAME didn't change. If
> you think the later library version is so incompatible that an
> application compiled against the earlier one must not use the later one
> then you must change SONAME too. If you believe them to be compatible
> enough and don't change SONAME then you must not change the symbol
> versions either (at least symbols that already existed in the older
> version). So you should use library-specific versions based on SONAME,
> not a global FFmpeg one (at least if you don't change SONAMEs globally
> too for every different version).
Okay, I've now implemented your suggestion and extended the configure
script to create a version script for each FFmpeg shared library with an
SONAME specific version, just as you suggest. The necessary changes were
rather straight forward to implement, but I want to clean them a bit up
before proposing them properly.
While doing this, I noticed this:
+ /var/tmp/ffmpeg/bin/ffmpeg -version
/var/tmp/ffmpeg/bin/ffmpeg: relocation error: /var/tmp/ffmpeg/bin/ffmpeg: symbol av_destruct_packet, version LIBAVFORMAT_\
52 not defined in file libavformat.so.52 with link time reference
After a bit of research, I found this commit:
,----
| ------------------------------------------------------------------------
| r18353 | rbultje | 2009-04-07 18:31:14 +0000 (Di, 07. Apr 2009) | 7 lines
|| Move av_packet_*() functions from libavformat/ to libavcodec/, where the
| AVPacket structure now resides also.
|| Patch by Thilo Borgmann thilo.borgmann googlemail com, see the mailinglist
| thread "Google Summer of Code participation" for additional discussion.
`----
Doesn't this patch break the ABI of libavformat because public functions
that have been exported formerly have been removed? Strictly speaking, I
think that's exactly what's happening here.
Why hasn't this been detected or caused any trouble? That's because
libavformat links against libavcodec, were the functions now reside.
Because libavformat links against libavcodec directly, the symbols for
these functions are guaranteed to be available and the ABI breakage of
libavformat does not come into effect for applications.
However, when symbols versioning comes into play, this breakage becomes
visible: The old ffmpeg binary searches av_destruct_packet with the tag
LIBAVFORMAT_52. In FFmpeg trunk that symbol is only available with the
tag LIBAVCODEC_52. So symbol versioning causes the dynamic linker to
behave more strictly than without.
Michael, would you (re-)consider bumping SONAME as an appropriate
approach to deal with the issues discussed in this mail?
--
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4