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

[Reinhard Tartler]

On Wed, Jun 09, 2010 at 15:10:18 (CEST), Michael Niedermayer wrote:

> On Wed, Jun 09, 2010 at 06:23:36AM +0200, Reinhard Tartler wrote:
>> On Wed, Jun 09, 2010 at 03:08:29 (CEST), Michael Niedermayer wrote:
>> 
>> > On Mon, Jun 07, 2010 at 01:11:41PM +0200, Reinhard Tartler wrote:
>> >> On Mo, Jun 07, 2010 at 12:52:14 (CEST), Michael Niedermayer wrote:
>> >> 
>> >> > On Mon, Jun 07, 2010 at 09:42:42AM +0200, Reinhard Tartler wrote:
>> >> >> 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? 
>> >> >
>> >> > i do
>> >> 
>> >> OK. I agree that we should unneccessarily do such breakages, not even in
>> >> trunk nor elsewhere.
>> >> 
>> >> >
>> >> >> 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 future moves, is there a problem with moving the symbols and
>> >> > updating the version script in the new home so it matches the version
>> >> > of the old (@LIBAVFORMAT in lavc for the specific symbols)
>> >> > ?
>> >> 
>> >> We could, but this wouldn't help. As you already noticed, ld-linux.so
>> >> obviously really expects the versioned symbol to be in libavformat:
>> >
>> > another try
>> > assume
>> > foobar at libavformat1 in libavformat
>> 
>> that would be 'foobar@@libavformat1'. Symbols by the linker script
>> always get tagged as 'default' symbol.
>
> fine, so s/@/@@/g
>
>
>> 
>> > to move:
>> > add foobar at libavformat1 in libavcodec
>> > mark foobar at libavformat1 in libavformat as weak symbol
>> > and put the whole foobar in libavformat under #if
>> > does this work?
>> > i think it should, ld.so favors globals over weak
>> 
>> we are talking about public symbols only here. Since libavformat always
>> includes libavcodec's public headers, you will always get redeclarations
>> errors for the offending function.
>
> void functA();
>
> void __attribute__((weak)) functA(){
>     printf(" libA0 ");
> }

Two questions:
 a) doesn't this attribute need to be at symbol declaration and not
    definition?
 b) How do you call the 'non-weak' symbol in lavc? Or do you propose to
    duplicate code? 

> compiled with -W -Wall -pedantic shows no errors and no warnings
> (it would be a bug imo if it did)
>
>
>>  Putting them in a seperate compilation unit that does not include
>> libavcodec's public headers won't work either, because the
>> implementation of these compat symbols would just call the now moved
>> symbols.
>
> that would depend on the implementation i guess, also strictly speaking
> nothing should ever call the weak symbols, they are overridden by global
> symbols. (iam not 100% sure abut -Bsymbolic and vissibility effects on this)

I'm pretty sure that it does have effects.

>> 
>> IMO the proper solution for this scenario is to
>> 
>> add  foobar@@libavcodec1 in libavcodec
>> add  ff_compat_foobar@@libavformat1 in libavformat that just calls foobar at libavcodec1
>> add  foobar at libavformat1 as alias in libavformat
>> 
>> NB: the syntax '@@' vs. '@'.
>> 
>> I still claim that step 3 is supported by all relevant platforms, even
>> ARM RVCT. Any counterexamples?
>
> your solution adds overhead aka it slows the code down

That's why my proposed dummy functions emit a runtime warning that
suggests to recompile the application for performance reasons.

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