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

I don't understand what point you're trying to make.

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

Yes, it can probably be done.  Whereas gcc uses asm() to inject a
.symver directive into the assembler output, armcc uses (gcc-style)
assembler labels to rename the functions.

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

Did you test it on RCVT?  I suspect not.

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

The patch you have shown does not work on armcc.  Since armcc does
support generating the symbol versions, we can of course arrange
macros to make it happen.  I'll try to find time for some testing
things out during the week.

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

You're right.  I didn't think of that.  It will need to be extended to
check for the armcc syntax too of course.

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