[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 09:17:56AM +0100, M?ns Rullg?rd wrote:
>> 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.
>
> a lib that has a version script of
> ver1{
>     global:foo;
> };
> ver2{
>     global:bar
> }ver1;
>
> this is a standard script, no tricks here
>
> an application that is written to use ver2 of this lib will
> get linked with bar at ver2 and foo at ver1
>
> thus the API and ABI of foo at ver1 must match ver2

I don't understand what you're trying to say.  There is no foo at ver2,
and bar at ver2 is almost certainly _not_ compatible with bar at ver1, or
there'd be no need for the two versions in the first place.

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