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

[Måns Rullgård]

Reinhard Tartler <siretart at tauware.de> writes:

> On So, Jun 06, 2010 at 17:59:48 (CEST), M?ns Rullg?rd wrote:
>
>> Reinhard Tartler <siretart at tauware.de> writes:
>>
>>> Hi,
>>>
>>> I'm sorry for not noticing earlier, but during upgrade tests, I noticed
>>> that there are some functions that went missing in libavformat.so.52
>>> since ffmpeg 0.5. In total, they are:
>>>
>>> void ff_av_destruct_packet_nofree(AVPacket *pkt);
>>> void ff_av_destruct_packet(AVPacket *pkt);
>>> int ff_av_new_packet(AVPacket *pkt, int size);
>>> int ff_av_dup_packet(AVPacket *pkt);
>>> void ff_av_free_packet(AVPacket *pkt);
>>> void ff_av_init_packet(AVPacket *pkt);
>>>
>>> They all were moved quite some time ago from libavformat to libavcodec.
>>> The API has not been broken, as avcodec is a dependency for avformat.
>>> Still, this is a serious problem if we want to retain binary
>>> compatibility. As a testcase, I'm using the ubuntu ffplay binary (ffmpeg
>>> 0.5) with a LD_LIBRARY_PATH, in which ffmpeg 0.6 libraries have been
>>> installed to playback a VP8 file in a WEBM container. Using this setup,
>>> ffplay aborts with:
>>>
>>> ffplay: relocation error: ffplay: symbol av_init_packet, version LIBAVFORMAT_52 not defined in file libavformat.so.52 with link time reference
>>>
>>> The message is exactly right; the mentioned symbols have been removed
>>> from libavformat.so.52.
>>>
>>> The safest fix in this situation would be of course to bump major.
>>
>> I think that is the proper thing to do.  We already have over 30
>> changes queued up for the next lavf major bump.  Piling on hacks will
>> merely delay the inevitable and has no long-term benefit.
>
> Well, by not bumping SONAME existing binaries and applications would
> benefit. I've descriped the ffplay binary from ffmpeg 0.5 as example
> application that now can playback VP8/WEBM while it hasn't been
> available at that time. But anyway, bumping SONAME would work for me as
> well.

And when we eventually do bump the major version, compatibility will
be lost again.  What's the big deal?

If you get rid of the __asm__ hackery, I do not, however, object to
having these wrappers in lavf for a while.

>>> +__asm__(".symver ff_av_destruct_packet_nofree,av_destruct_packet_nofree at LIBAVFORMAT_52");
>>
>> This will break with non-gcc compilers and/or non-gnu assemblers, both
>> of which we support.
>
> I don't think so. I've changed the configure script so that this part
> gets only compiled if the toolchain actually supports versioning
> scripts. On non-gnu assemblers/compilers, this part doesn't get compiled
> at all.

You are mistaken.  The configure test checks whether the _linker_
supports version scripts.  The code above relies on the _compiler_
supporting this particular inline asm syntax, which some supported
compilers do not, and on the _assembler_ supporting the .symver
directive, which again some supported assemblers do not.

Can this be done in the version script instead?

-- 
M?ns Rullg?rd
mans at mansr.com