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

[Michael Niedermayer]

On Thu, Jun 10, 2010 at 12:15:00PM +0200, Michael Niedermayer wrote:
> On Thu, Jun 10, 2010 at 11:38:52AM +0200, Michael Niedermayer wrote:
> > On Thu, Jun 10, 2010 at 09:52:13AM +0100, M?ns Rullg?rd wrote:
> > > 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
> > > >>>     definition?
> > > >>
> > > >> 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
> > > > propose:
> > > >
> > > > #if LIBAVFORMAT_VERSION_MAJOR < 53
> > > > [...]
> > > > void __attribute__((weak)) av_init_packet(AVPacket *pkt)
> > > > {
> > > >      abort();
> > > > }
> > > > #endif
> > > >
> > > > 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.
> > 
> > until reinhard posts a readelf of libavcodec that shows a global
> > av_init_packet at LIBAVFORMAT_52 this conclusion is unfounded
> 
> also in case its not clear to anyone, this proposal is of course primarely
> intended for future symbol moves. The current move has the problem of a
> previous av_init_packet at LIBAVCODEC in lavc.
> (iam saying that before someone post a "it doesnt find av_init_packet at LIBAVCODEC
>  anymore with old binaries")

and theres another difference between the symver asm forwarding stubs vs.
weak symbols. the symver asm stubs will produce differing addresses for the
symbols, which with av_destruct_packet* may cause problems and with
variables instead of functions will not work at all as variables cant be
forwarded like it was suggested for the functions.


[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

I have often repented speaking, but never of holding my tongue.
-- Xenocrates
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20100610/ca91e63b/attachment.pgp>