[FFmpeg-devel] [PATCH] restoring binary compatibility with ffmpeg 0.5

Reinhard Tartler siretart
Thu Jun 10 17:12:53 CEST 2010


On Thu, Jun 10, 2010 at 17:04:45 (CEST), M?ns Rullg?rd wrote:

> Michael Niedermayer <michaelni at gmx.at> writes:
>
>> On Mon, Jun 07, 2010 at 07:24:30AM +0200, Reinhard Tartler wrote:
>>> On So, Jun 06, 2010 at 22:29:25 (CEST), Reimar D?ffinger wrote:
>>> 
>>> > However here we have the problem that this would break e.g. on Solaris,
>>> > since a symbol is not allowed to have multiple versions there.
>>> > I think the real mistake was made during the move: the version should
>>> > never have been changed, despite the move to a different library...
>>> > Am I right that changing the linker script to
>>> > LIBAVFORMAT_52 {
>>> >         global: av_init_packet;
>>> > };
>>> > LIBAVCODEC_$MAJOR {
>>> >         global: *;
>>> > };
>>> > would avoid the compatibility issue with 0.5 (though breaking it
>>> > for several versions in-between)?
>>> 
>>> I've tried this as well, but unfortunately, this doesn't work out:
>>> 
>>> >> objdump -T /tmp/ffmpeg/lib/libavcodec.so.52 | grep av_init_packet
>>> 000c0ce0 g    DF .text	00000058  LIBAVFORMAT_52 av_init_packet
>>> 
>>> >> ffplay /tmp/Elephants_Dream-720p-Stereo.webm
>>> FFplay version SVN-r0.5.1-4:0.5.1-1ubuntu1, Copyright (c) 2003-2009 Fabrice Bellard, et al.
>>>   configuration: --extra-version=4:0.5.1-1ubuntu1 --prefix=/usr --enable-avfilter --enable-avfilter-lavf --enable-vdpau --enable-bzlib --enable-libgsm --enable-libschroedinger --enable-libspeex --enable-libtheora --enable-libvorbis --enable-pthreads --enable-zlib --disable-stripping --disable-vhook --enable-runtime-cpudetect --enable-gpl --enable-postproc --enable-swscale --enable-x11grab --enable-libdc1394 --enable-shared --disable-static
>>>   libavutil     49.15. 0 / 49.15. 0
>>>   libavcodec    52.20. 1 / 52.72. 2
>>>   libavformat   52.31. 0 / 52.64. 2
>>>   libavdevice   52. 1. 0 / 52. 2. 0
>>>   libavfilter    0. 4. 0 /  0. 4. 0
>>>   libswscale     0. 7. 1 /  0.11. 0
>>>   libpostproc   51. 2. 0 / 51. 2. 0
>>>   built on Mar  4 2010 12:35:30, gcc: 4.4.3
>>> ffplay: relocation error: ffplay: symbol av_init_packet, version LIBAVFORMAT_52 not defined in file libavformat.so.52 with link time reference
>>> 
>>> It seems that this symbol really needs to be in libavformat.
>>
>> Following fixes it (at least with my ld.so, ive not tried it without the
>> other bugfixes, but ill look into it if that alone doesnt work for you)
>>
>> I think its reasonable if the ffmpeg project requires a linker that is not
>> full of such arbitrary failure conditions.
>
> I think it is totally unreasonable that to require a linker that
> doesn't exist and doesn't stand a chance in hell of ever existing, no
> matter how superior it may be technically, morally, or otherwise.

I totally agree. Moreover, I can very well imagine that existing
applications rely on this particular behavior.

>> Also iam quite curious how solaris and other pre/non gnu systems handle this.
>> Its really silly to fail just because a symbol is moved from libA to a
>> dependancy of libA (and then only if versioning is enabled)
>
> Silly or not, this is how things work, and we have to live with it.

moreover, there are approaches to address this.

-- 
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4




More information about the ffmpeg-devel mailing list