[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 21:18:31 (CEST), M?ns Rullg?rd wrote:
>
>> 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.
>
> for the record. mru and I have discussed this a bit further on IRC, and
> mru's concern here is that he insists on a fix that works on all, even
> on non gnu platforms and objects to a fix that only works on gcc
> platforms.
>
> So far, I think we agreed that bumping SONAME on libavcodec will work
> for everyone.  Moreover, I checked with others that confirmed that
> fixing this really needs the gcc extensions to the linker script.
>
> In any case, find below the 'best' fix, that admittedly only works on
> gnu platforms. Michael, please comment if you prefer the half fix that
> fixes the issue on gcc/gas platforms (and doesn't regress on others) or
> bumping major of libavformat.

We _already_ have a regression, which we unfortunately didn't discover
until now.  Leaving it broken on some platforms while fixing others is
simply not acceptable.

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