[FFmpeg-devel] [PATCH] restoring binary compatibility with ffmpeg 0.5
Thu Jun 10 10:52:13 CEST 2010
Reinhard Tartler <siretart at tauware.de> writes:
> On Wed, Jun 09, 2010 at 19:41:33 (CEST), Michael Niedermayer wrote:
>> On Wed, Jun 09, 2010 at 03:42:13PM +0200, Reinhard Tartler wrote:
>>> Two questions:
>>> a) doesn't this attribute need to be at symbol declaration and not
>> The way i understand it, it needs to be at the definition
>> at the declaration it possibly means a weak refernce which is something
>> that is 0 (instead of failing to link) if no definition is found
> I see.
> I've now tried your suggestion to (re)introduce the functions like you
> #if LIBAVFORMAT_VERSION_MAJOR < 53
> void __attribute__((weak)) av_init_packet(AVPacket *pkt)
> building a shared libavformat.so works without warnings/errors regarding
> symbol collisions and results this
> $ readelf -s /tmp/ffmpeg-trunk/lib/libavformat.so | grep av_init_packet@
> 466: 000abc00 8 FUNC WEAK DEFAULT 13 av_init_packet@@LIBAVFORMAT_52
> I guess this is exactly what you've expected here.
> With this setup, I've now tried both the ffplay binary from this
> compilation and the system /usr/bin/ffplay (based on version 0.5.2). In
> *both* cases, it seems that the binary at runtime picks up the version
> in libavformat:
>>> readelf -s /tmp/ffmpeg-trunk/bin/ffplay | grep av_init_packet
> 49: 00000000 0 FUNC GLOBAL DEFAULT UND av_init_packet at LIBAVFORMAT_52 (10)
>>> /tmp/ffmpeg-trunk/bin/ffplay /tmp/foo.avi
> FFplay version SVN-r23556, Copyright (c) 2003-2010 the FFmpeg developers
> built on Jun 10 2010 08:09:17 with gcc 4.4.3
> configuration: --enable-avfilter --enable-libvpx --enable-shared --disable-static --enable-gpl --prefix=/tmp/ffmpeg-trunk --enable-postproc --enable-libvorbis
> libavutil 50.18. 0 / 50.18. 0
> libavcodec 52.75. 1 / 52.75. 1
> libavformat 52.68. 0 / 52.68. 0
> libavdevice 52. 2. 0 / 52. 2. 0
> libavfilter 1.20. 0 / 1.20. 0
> libswscale 0.11. 0 / 0.11. 0
> libpostproc 51. 2. 0 / 51. 2. 0
> zsh: abort /tmp/ffmpeg-trunk/bin/ffplay /srv/media/UDS-Sevilla.avi
This is what I would expect. The weak attribute is only used when
combining relocatable object files in to an executable or shared
object, not during runtime dynamic linking.
>>> b) How do you call the 'non-weak' symbol in lavc? Or do you propose to
>>> duplicate code?
>> I do not know in which cases the symbol can be called
>> If it cant ever then an empty function with assert(0) should do.
> Well, my original patch used dlopen() to force using the symbols from
> libavcodec.so.52. This should work in any case, but I guess this is not
> what we want here.
I don't see any benefit from using dlsym there. It still needs to
perform an extra function call.
mans at mansr.com
More information about the ffmpeg-devel