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

[Michael Niedermayer]

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)

@@ -266,10 +277,10 @@
 	}
 
       /* If this current map is the one mentioned in the verneed entry
-	 and we have not found a weak entry, it is a bug.  */
-      if (symidx == STN_UNDEF && version != NULL && version->filename != NULL
-	  && __builtin_expect (_dl_name_match_p (version->filename, map), 0))
-	return -1;
+	 and we have not found a weak entry, it is a bug in this code thus outcommented.  */
+//      if (symidx == STN_UNDEF && version != NULL && version->filename != NULL
+//	  && __builtin_expect (_dl_name_match_p (version->filename, map), 0))
+//	return -1;
     }
   while (++i < n);

I think its reasonable if the ffmpeg project requires a linker that is not
full of such arbitrary failure conditions.
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)

note to mans, above changes a failure to non failure it thus should not
affect code that succeeded at linking.

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

Avoid a single point of failure, be that a person or equipment.
-------------- 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/22089089/attachment.pgp>