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

[Reinhard Tartler]

On Wed, Jun 09, 2010 at 10:30:29 (CEST), M?ns Rullg?rd wrote:

> Reinhard Tartler <siretart at tauware.de> writes:
>
>> On Wed, Jun 09, 2010 at 01:59:18 (CEST), M?ns Rullg?rd wrote:
>>
>>> Reinhard Tartler <siretart at tauware.de> writes:
>>>
>>>> and my own tests to compile ffmpeg with sun's cc failed miserably.
>>>
>>> The FATE machine seems to build it, although it fails many tests.
>>> Failing tests are only valid as arguments for non-support if little
>>> hope exists for a future fix.  I don't know where suncc stands on this
>>> at the moment.
>>>
>>>> Even opencsw/blastwave seem to prefer gcc here.
>>>
>>> Not relevant.
>>
>> Well, I take that as indication that sun cc is not relevant for this
>> discussion.
>
> I don't know what those are, but they're not ffmpeg.  Hence irrelevant.

great.

>>>> 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.
>>>
>>> The Linux kernel does not use symbol versioning.  Your assumption is
>>> thus invalid.
>>>
>>>> So what notable platforms are left?
>>>
>>> ARM RVCT.  This compiler is fully supported and works very well indeed.
>>
>> I've just checked it's documentation at
>> http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0474a/Beihfhej.html
>>
>> AFAIUI, this compiler a) supports the specific asm syntax that I've used
>> in my patch,
>
> It does not.  Not even close.

Okay, the exact syntax may be a bit different, but nothing that we
couldn't solve with some macros.

>> and b) does support multiple versions of the same symbol in exactly
>> the same syntax as GCC.
>
> GCC is not involved apart from the inline asm.  Whatever linker armcc
> uses supports the versioning.

sure

>>>>> 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.
>>>
>>> That would pointlessly disable the useful symbol versioning for those
>>> compilers which fail the test.  That is IMO not a good "solution".
>>
>> It's not pointless, it disables symbol versioning for compilers for
>> platforms for which are a) very obscure and b) hard to find a
>> propoer solution.
>
> The preset problem can be solved with a recompile of the affected
> app.  The problems solved by the symbol versioning cannot. Do you
> prefer an unsolvable problem over a solvable one?

I have shown an approach an approach that works on both gnu toolchains
and on ARM RCVT. My proposed patch currently only considers gnu ld, but
that can be extended. Other (supported) platforms have not been
mentioned.

AFAIUI we have two options:

 - bump soname, rejected by michael
 - provide multiple symbols for the same lib, which works for all
   relevant toolchains/platforms discussed in this thread so far, but
   rejected by you (mans)

This discussion is becoming wearisome as no new arguments are being
added. can we come to _some_ conclusion?

>
>>>> 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
>>>
>>> This should use check_asm, but don't bother with an update until you
>>> manage to convince me it should be done.  That will be difficult.
>>
>> No, the point of using check_cc here is to test that the compiler
>> supports that particular asm syntax as well. This was an requirement
>> from you in an earlier post of this thread.
>
> That is exactly what check_asm does.

No it doesn't.

check_asm() inserts the asm statement inside a dummy function. The
documentation requires the asm statement to be placed at global scope.

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