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

[Reinhard Tartler]

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.

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

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?

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