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

[Reinhard Tartler]

On Mo, Jun 07, 2010 at 10:40:04 (CEST), Michael Niedermayer wrote:

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

did you try that? In my tests, I get these compiler errors:

causes this compiler error:
.../ffmpeg/libavformat/utils.c:326: error: redefinition of 'av_init_packet'
.../ffmpeg/libavformat/utils.c:325: note: previous definition of 'av_init_packet' was here


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

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