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

Reinhard Tartler siretart
Sun Jun 6 21:38:07 CEST 2010


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.

Index: configure
===================================================================
--- configure	(revision 23498)
+++ configure	(working copy)
@@ -1086,6 +1086,7 @@
     struct_sockaddr_in6
     struct_sockaddr_sa_len
     struct_sockaddr_storage
+    symbol_versioning
     sys_mman_h
     sys_resource_h
     sys_select_h
@@ -2733,8 +2734,13 @@
 
 echo "X{};" > $TMPV
 test_ldflags -Wl,--version-script,$TMPV &&
-    append SHFLAGS '-Wl,--version-script,\$(SUBDIR)lib\$(NAME).ver'
+    append SHFLAGS '-Wl,--version-script,\$(SUBDIR)lib\$(NAME).ver' &&
+    check_cc <<EOF && enable symbol_versioning
+int ff_foo() {}
+__asm__(".symver foo,av_foo at SOME_TAG");
+EOF
 
 if enabled small; then
     add_cflags $size_cflags
     optimizations="small"
Index: libavformat/utils.c
===================================================================
--- libavformat/utils.c	(revision 23498)
+++ libavformat/utils.c	(working copy)
@@ -282,9 +282,53 @@
     return NULL;
 }
 
-/* memory handling */
+#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)
+{
+    av_destruct_packet_nofree(pkt);
+}
+__asm__(".symver ff_av_destruct_packet_nofree,av_destruct_packet_nofree at LIBAVFORMAT_52");
 
+void ff_av_destruct_packet(AVPacket *pkt);
+void ff_av_destruct_packet(AVPacket *pkt)
+{
+    av_destruct_packet(pkt);
+}
+__asm__(".symver ff_av_destruct_packet,av_destruct_packet at LIBAVFORMAT_52");
+
+int ff_av_new_packet(AVPacket *pkt, int size);
+int ff_av_new_packet(AVPacket *pkt, int size)
+{
+    return av_new_packet(pkt, size);
+}
+__asm__(".symver ff_av_new_packet,av_new_packet at LIBAVFORMAT_52");
+
+int ff_av_dup_packet(AVPacket *pkt);
+int ff_av_dup_packet(AVPacket *pkt)
+{
+    return av_dup_packet(pkt);
+}
+__asm__(".symver ff_av_dup_packet,av_dup_packet at LIBAVFORMAT_52");
+
+void ff_av_free_packet(AVPacket *pkt);
+void ff_av_free_packet(AVPacket *pkt)
+{
+    av_free_packet(pkt);
+}
+__asm__(".symver ff_av_free_packet,av_free_packet at LIBAVFORMAT_52");
+
+void ff_av_init_packet(AVPacket *pkt);
+void ff_av_init_packet(AVPacket *pkt)
+{
+    av_log(NULL, AV_LOG_WARNING, "diverting av_*_packet function calls to libavcodec. Recompile to improve performance\n");
+    av_init_packet(pkt);
+}
+__asm__(".symver ff_av_init_packet,av_init_packet at LIBAVFORMAT_52");
+#endif
+
 int av_get_packet(ByteIOContext *s, AVPacket *pkt, int size)
 {
     int ret= av_new_packet(pkt, size);


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




More information about the ffmpeg-devel mailing list