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

[Måns Rullgård]

Michael Niedermayer <michaelni at gmx.at> writes:

>> >> >> It changes the name of the symbol.  Anything linked against current
>> >> >> libavcodec will fail after this change.
>> >> >
>> >> > IMO the linker is suposed to find symbols in the linked versions
>> >> > gnu ldso does not, so this doesnt work for us. I still think though
>> >> > that this behavior of gnu ldso is not terribly sane
>> >> 
>> >> How do you expect it to figure that a differently named symbol is
>> >> actually the same thing?  If an app lists foo at LIBAVFORMAT_52 as an
>> >> undefined symbol, some library must provide that exact name.  For
>> >> dynamic symbol resolution, the version tag is effectively part of the
>> >> symbol name.
>> >
>> > readelf -a
>> > for a lib linked with:
>> > LIBC0VER
>> > {
>> >  global:
>> >     functA;
>> > };
>> > LIBA0VER
>> > {
>> >  global:
>> >   *;
>> > }LIBC0VER;
>> >
>> > says:
>> >   000000: Rev: 1  Flags: BASE   Index: 1  Cnt: 1  Name: libA0.so
>> >   0x001c: Rev: 1  Flags: none  Index: 2  Cnt: 1  Name: LIBC0VER
>> >   0x0038: Rev: 1  Flags: none  Index: 3  Cnt: 2  Name: LIBA0VER
>> >   0x0054: Parent 1: LIBC0VER
>> >
>> > so the parent version seems stored in the elf so. And i had naively
>> > assumed that ldso would search it too
>> 
>> You're looking in the wrong place.  The .dynsym table is the relevant
>> one here.
>
> you misunderstand me, i just meant to point out that the information is
> in the ELF file. And i had assumed that ldso could use it which at least
> gnus does not.
> more precissely if it tries to find a foobar at LIBA0VER and fails to find
> it, it could inside this lib retry with foobar at LIBC0VER

Those versions might not be compatible.  There is no way to know.

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