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

[Reinhard Tartler]

On Thu, Jun 10, 2010 at 20:16:31 (CEST), Michael Niedermayer wrote:

> On Thu, Jun 10, 2010 at 05:12:53PM +0200, Reinhard Tartler wrote:
>> 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.
>
> so you are basically saying that shortcomings in the linker should never be
> fixed but everyone should work around them.
> if thats not unreasonable than nothing is.
>
> Either way your rant doesnt change it
> moving a symbol with enabled versioning requires a soname bump or asm symver
> tricks with the gnu linker.
> you (mans) objected to symver tricks (and i dont really like them either,
> though objecting might be unreasonable given the lack of
> alternatives),

AFAIUI, mans wanted to reconsider the symver tricks if they can be made
work with ARM RCVT as well. Mans, is this correct? Are you working on
that or do you want me to prepare a patch so that you can test it?

If yes, i'm considering fixing it for gnu toolchains only for 0.6, and
hand fixes for other toolchains like ARM RCVT in later with 0.6.1.

> and i object to soname bumps
> thus its just not going to work with the gnu linker like it or not,
> unreasonable or not.
> And a single line change in the linker fixes it
> Its ok if people choose not to fix the linker but i choose not to workaround
> its bugs either.
> Whats left is
> 1. Perform symbol moves so that they work with the hypothetical fixed linker
> 2. Completely ignore the issue and let the distro maintainers deal with it

In that case, I'd certainly ship my "half-fix" as distro patch. In that
case, 0.6 is (IMO) ready for release. Diego?

> 3. Something we missed
>
> doing 1 is not hurting the existing linkers compared to 2 thus i must say
> calling it unreasonable is in itself a bit unreasonable.
>
>> 
>> I totally agree. Moreover, I can very well imagine that existing
>> applications rely on this particular behavior.
>
> elaborate please, if the issue is real it likely can be fixed

I wonder if this issue is related to
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24660.

what is actually the precise symptom of this bug? The fact that the
runtime linker should not consider the version tag for 'weak' symbols?
As master thesis [1], I've written a dynamic aspect weaver for C++, where
the base application was instrumented by inserting weak symbols. At
runtime, dynamic aspects (basically extension modules) shipped non-weak
symbols that override the weak ones, which was then used to change the
behavior of the base application.  The implementation of this approach
will only work if the linker would only 'overload' those weak symbols
that have matching version tags. Moreover, if the base implementation
had symbols with different version, the extension module could override
both with different implementations (which in this specific application
probably wouldn't make too much sense, but it gives an idea).

[1] now pending publication as journal article, see
http://univis.uni-erlangen.de/prg?search=publications&id=91082516&show=bibtex


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