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

[Måns Rullgård]

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.

>>> 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.

> 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.

>>>> 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?

>>> 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.

-- 
M?ns Rullg?rd
mans at mansr.com