[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 20:01:44 (CEST), M?ns Rullg?rd wrote:
>
>> 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.
>
> I don't really like them either, but I fear there is no other way here.

Then this exercise is pointless.  Unless we can find a way to create
these aliases using only linker tricks, our only recourse is to bump
major.

>>>>> +__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?
>
> no, it cannot. This .symver directive is a gnu extension to the sun
> implementation.
>
> Perhaps you can propose a better configure check?

That would be pointless since it would leave non-gcc/gas
configurations just as "broken" as they are now.

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