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

[Michael Niedermayer]

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")

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

He who knows, does not speak. He who speaks, does not know. -- Lao Tsu
-------------- 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/2f036487/attachment.pgp>