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

[Michael Niedermayer]

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 ");
}

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)


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

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

While the State exists there can be no freedom; when there is freedom there
will be no State. -- Vladimir Lenin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20100609/927f1af8/attachment.pgp>