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

Michael Niedermayer michaelni
Mon Jun 7 10:54:22 CEST 2010


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


[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

No great genius has ever existed without some touch of madness. -- Aristotle
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20100607/46062696/attachment.pgp>



More information about the ffmpeg-devel mailing list