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

[Reinhard Tartler]

On Tue, Jun 08, 2010 at 20:44:41 (CEST), Michael Niedermayer wrote:

> On Tue, Jun 08, 2010 at 04:41:19PM +0200, Reinhard Tartler wrote:
>> On Mon, Jun 07, 2010 at 10:20:45 (CEST), Reinhard Tartler wrote:
>> 
>> > On Mo, Jun 07, 2010 at 10:02:19 (CEST), M?ns Rullg?rd wrote:
>> >
>> >> Reinhard Tartler <siretart at tauware.de> writes:
>> >>
>> >>> On Mo, Jun 07, 2010 at 08:02:54 (CEST), Reimar D?ffinger wrote:
>> >>>
>> >>>> On Mon, Jun 07, 2010 at 07:52:11AM +0200, Reinhard Tartler wrote:
>> >>>>> void av_init_packet(AVPacket *pkt) av_weak_alias(av_init_packet);
>> >>>>> void 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);
>> >>>>
>> >>>> ff_internal_init_packet() and add one such to lavc.
>> >>>> Either way, we should make sure we have a solution the next time.
>> >>>> Since the @LIBAVFORMAT version is not accepted in lavc, does that
>> >>>> mean no matter what we do, we will always break ABI if we move code?!
>> >>>
>> >>> if I understand you correctly, you not only consider ABI breakages
>> >>> between releases, but also between any svn revision? Then I fear yes.
>> >>> However, the break is already there since quite some time, and fixing it
>> >>> to have it compatible to ffmpeg 0.5 has (or at least should have)
>> >>> priority, IMO.
>> >>
>> >> For the 0.6 release possibly.  For trunk I don't think that is
>> >> important.
>> >
>> > Agreed. Still, I'd prefer to not do drastic measures in 0.6 like
>> > prematurely bumping soname or something. How do people feel to apply my
>> > propsed "half-fix" to 0.6 only, and bump soname in trunk?
>> 
>> The discussion on this thread was very vivid but has now ended rather
>> abruptly, and this question remains unanswered.
>> 
>> Does anyone object to have this "half-fix" in 0.6 now, and leave it an
>> open issue for trunk until we either have found a better fix or bumped
>> SONAME? If someone needs more time to think about this, please say so.
>
> i have no awnser atm but i have a question
> how do we move symbols in the future from lavf->lavc / lavc->lavu ?
> this is something we have to do occasionally, and bumping soname is imo
> not reasonable for this.

I agree that it is pretty annoying, but I don't think it's unreasonable.

> In some sense the problem with symbol moving is a regression cause by
> enabling versioning.

Well, my 'half-fix' approach shows how to solve this on platforms with
gnu compilers and assemblers, which is not available on platforms that
support symbol versioning but don't support the used gcc extension to
provide mutliple versions of the same symbol.

However, I seriously ask what toolchains do we (aim to) support and
offer symbol versioning but not gcc's extension to provide different
versions of the same symbol.  AFAIUI, this is most notably the solaris
compiler, for which ffmpeg's support is pretty inferior: No single FATE
machine uses it, and my own tests to compile ffmpeg with sun's cc failed
miserably.  Even opencsw/blastwave seem to prefer gcc here. As for icc,
AFAIUI, they claim that they manage to compile the linux kernel, so I
strongly assume that they support the used asm syntax from my approach.

So what notable platforms are left?

> Also, once we know how to solve this in the future the solution might be
> applicable here too.

With these remarks, I propse to require gcc's support for symbols with
different versions and if the system compiler does not support it, then
disable symbol versioning altogether. This avoids a corner case that a)
is persumably very obscure and seldomly found and b) very hard to
support without agreesively bumping soname on every symbol move.

this approach is implemented by this change to configure:

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,7 +2734,10 @@
 
 echo "X{};" > $TMPV
 test_ldflags -Wl,--version-script,$TMPV &&
-    append SHFLAGS '-Wl,--version-script,\$(SUBDIR)lib\$(NAME).ver'
+    check_cc <<EOF append SHFLAGS '-Wl,--version-script,\$(SUBDIR)lib\$(NAME).ver' && enable symbol_versioning
+int ff_foo() { }
+__asm__(".symver foo,av_foo at SOME_TAG");
+EOF
 
 if enabled small; then
     add_cflags $size_cflags


> Without fixing ldso, the most reasonable if i didnt forget any sideeffects
> is to keep the symbols duplicated in the old lib under #if. This would
> lead to ld linking code randomly to old / new. Is this a actual
> problem?

With gcc's support for multiple versions of the same symbol, this is a
matter of selecting the default symbol properly. I've checked that my
proposed patch gets this right.

> Speaking of this, have you confirmed that your "half-fix" is linking
> to new and not old independant of lib order ?

Yes, during my first test, I indeed encountered that problem. My
proposed approachs gets this right, at least on Linux.

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