[FFmpeg-devel] [PATCH] restoring binary compatibility with ffmpeg 0.5
Sun Jun 6 21:03:55 CEST 2010
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:
>>>> 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
> 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
Perhaps you can propose a better configure check?
Reinhard Tartler, KeyID 945348A4
More information about the ffmpeg-devel