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

[Reinhard Tartler]

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.

>>>> +__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?

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