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

[Reinhard Tartler]

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.

>> I'd really like to have this for ffmpeg 0.6.
>
> That is ultimately for the release maintainers to decide, but please
> see comments below.
>
>> Is the attached patch acceptable for trunk?
>
> No.
>
>> +#if HAVE_SYMBOL_VERSIONING && LIBAVFORMAT_VERSION_MAJOR < 53
>> +/* compatibility trampolines for packet functions */
>>
>> +void ff_av_destruct_packet_nofree(AVPacket *pkt);
>> +void ff_av_destruct_packet_nofree(AVPacket *pkt)
>> +{
>> +    void (*fn)(AVPacket *pkt) = dlsym(avformat_handle, "av_destruct_packet_nofree");
>> +    if (!fn)
>> +        av_log(NULL, AV_LOG_FATAL, "Failed to locate symbol: av_destruct_nofree\n");
>> +    (*fn)(pkt);
>
> Aside, you don't need all those stars and parens.  A simple fn(pkt) is
> equivalent.

simplified with reimars suggestions.

>> +}
>
> Why not simply call the function directly?

right.

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

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