[FFmpeg-devel] [PATCH] restoring binary compatibility with ffmpeg 0.5
Mon Jun 7 10:54:35 CEST 2010
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");
>> - 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.
mans at mansr.com
More information about the ffmpeg-devel