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

[Michael Niedermayer]

On Mon, Jun 07, 2010 at 07:52:11AM +0200, Reinhard Tartler wrote:
> On Mo, Jun 07, 2010 at 01:44:30 (CEST), Michael Niedermayer wrote:
> 
> >> > we can duplicate the symbols and code in lavf under #if
> >> 
> >> I suspect that might cause a conflict during linking since the same
> >> symbol would be provided by two libraries.  If it doesn't fail, the
> >> version chosen is unpredictable.  We'd end up with apps linked against
> >> a mix of sym at LIBAVFORMAT_XX and sym at LIBAVCODEC_XX which is obviously
> >> not good.
> >
> > marking one as weak symbol might work.
> > weak symbols are part of the ELF spec ... doesnt mean gnu tools support
> > them of course ;)
> 
> I've (of course) tried that as well, but it doesn't work in this
> case. The problem here is that you must not create symbol collisions in
> the same compilation unit. Removing the symbols from libavcodec, even
> conditionally, is not an option that we have. Using weak symbols, like
> this version
> 
> #if HAVE_SYMBOL_VERSIONING && LIBAVFORMAT_VERSION_MAJOR < 53
> /* compatibility trampolines for packet functions */
> 
> #define av_weak_alias(x)  __attribute__ (( weak, alias ("x") ))
> 
> void av_init_packet(AVPacket *pkt) av_weak_alias(av_init_packet);
> void av_init_packet(AVPacket *pkt)

what about

void __attribute__ (( weak )) 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);
> }

?

[...]

>  - using weak symbols (doesn't support duplicate symbols)

elf spec:
Global and weak symbols differ in two major ways.
     When the link editor combines several relocatable object files, it does not allow multiple denitions
     of STB_GLOBAL symbols with the same name. On the other hand, if a defined global symbol
     exists, the appearance of a weak symbol with the same name will not cause an error. The link edi-
     tor honors the global definition and ignores the weak ones. Similarly, if a common symbol exists
     (i.e., a symbol whose st_shndx field holds SHN_COMMON), the appearance of a weak symbol with
     the same name will not cause an error. The link editor honors the common definition and ignores
     the weak ones.
     When the link editor searches archive libraries, it extracts archive members that contain definitions
     of undefined global symbols. The member definition may be either a global or a weak symbol.
     The link editor does not extract archive members to resolve undfiened weak symbols. Unresolved
     weak symbols have a zero value.



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

Rewriting code that is poorly written but fully understood is good.
Rewriting code that one doesnt understand is a sign that one is less smart
then the original author, trying to rewrite it will not make it better.
-------------- 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/20100607/78218f52/attachment.pgp>