[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 11:08:46AM +0200, Reinhard Tartler wrote:
>> 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
>
> i tried:
> int __attribute__((weak)) func(int x)
> {
>         return 5;
> }
>
> and i can make a .so out of that

Yes, it works (I tested), but the version picked up when linking
against two libs defining the same symbol is whichever the linker
finds first.  As I said earlier, this means that sometimes executables
will request the @LIBAVFORMAT version and sometimes the @LIBAVCODEC
one.  We do not want that situation.

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