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

[Reinhard Tartler]

On Wed, Jun 09, 2010 at 01:59:18 (CEST), M?ns Rullg?rd wrote:

> Reinhard Tartler <siretart at tauware.de> writes:
>
>> 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.
>
> It seems to be an unavoidable effect of the symbol versioning.
> Considering that symbol versioning solved an actually observed
> problem, that this issue has not yet been fingered in the wild, and
> that symbol moves like this are in fact quite rare, I agree with this
> assessment.
>
>>> 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,
>
> What are these then?
>
> http://fate.multimedia.cx/index.php?history=build&config_id=166
> http://fate.multimedia.cx/index.php?history=build&config_id=167

Narf, there they are. I do remember having seen those builds in the
past, but yesterday evening I've didn't find them, not even with my
browser's search function. strange. but anyway.

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

>> 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, and b) does support multiple versions of the same symbol in
exactly the same syntax as GCC.


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

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

>>> 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.
>
> I would expect that.  The compat symbols will not have a default
> version, so the real one will be used.  Or something like that.

exactly.

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