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

[Michael Niedermayer]

On Mon, Jun 07, 2010 at 11:06:56AM +0100, M?ns Rullg?rd wrote:
> Michael Niedermayer <michaelni at gmx.at> writes:
> 
> > 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
[...]
> The version script is not
> available to users of the library, so anything you think you might
> infer from the script is simply irrelevant.

see above, the information is available to users of the lib


> 
> > 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
> 
> Perhaps what you describe would be useful in some scenario.  It is
> however NOT WHAT ACTUALLY HAPPENS.  You must distinguish between what
> things do and what you would like them to do.

i simply showed the consequences of a set of assumtations.
i dont claim these assumtations to apply in all cases

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

When you are offended at any man's fault, turn to yourself and study your
own failings. Then you will forget your anger. -- Epictetus
-------------- 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/2a1f1bb9/attachment.pgp>