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

[Måns Rullgård]

Michael Niedermayer <michaelni at gmx.at> writes:

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

That still relies on the compiler supporting this attribute, which
some of them do not, so it's out of the question.

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

But that's not what we're doing here.  We're using multiple shared
objects to resolve the undefined symbols while creating an executable.

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

This is all talking about combining multiple object files into a
single executable or shared object, not resolving symbols against
multiple shared objects.

-- 
M?ns Rullg?rd
mans at mansr.com