[FFmpeg-devel] [PATCH] restoring binary compatibility with ffmpeg 0.5
Sun Jun 6 20:01:44 CEST 2010
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.
>>> +__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?
mans at mansr.com
More information about the ffmpeg-devel