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

[Michael Niedermayer]

On Mon, Jun 07, 2010 at 10:14:54AM +0100, M?ns Rullg?rd wrote:
> 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.

yes

what iam trying to say is that with the way versioning is intended to be
used (as in suns docs) foo should be compatible

the use case from sun (IIRC) is that an application uses various functions
and there is one lib that provides the symbols during linking with ld
ld will for this look into the versioning script to find out since which
version each symbol was available (see version script above as example)
from this ld will know which is the minimum library version on which
the application depends.
With our example above an application using just foo will require ver1 or
later. but if it uses bar it will require ver2 or later

if you consider now that there exists a foo at ver2 that is incompatible
with foo at ver1 then this very litterally contradicts the very version
script above, which really says that they are compatible.
compatible in the sense that an application using ver2 will with this
version script be linked to foo at ver1 by ld and ld.so

iam not saying you cannot create a foo at ver2 that is incompatible
iam saying that if versions as specified in a version script correspond
to some documented API/ABIs it would violate this documentation with the
version script example

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

No snowflake in an avalanche ever feels responsible. -- Voltaire
-------------- 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/c3b63b0e/attachment.pgp>