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

[Michael Niedermayer]

On Mon, Jun 07, 2010 at 08:46:37AM +0100, M?ns Rullg?rd wrote:
> Michael Niedermayer <michaelni at gmx.at> writes:
> 
> > On Sun, Jun 06, 2010 at 11:42:49PM +0100, M?ns Rullg?rd wrote:
> >> Michael Niedermayer <michaelni at gmx.at> writes:
> >> 
> >> > On Sun, Jun 06, 2010 at 10:32:19PM +0100, M?ns Rullg?rd wrote:
> >> >> Michael Niedermayer <michaelni at gmx.at> writes:
> >> >> 
> >> >> > On Sun, Jun 06, 2010 at 10:59:09PM +0200, Reimar D?ffinger wrote:
> >> >> >> On Sun, Jun 06, 2010 at 10:45:18PM +0200, Michael Niedermayer wrote:
> >> >> >> > On Sun, Jun 06, 2010 at 10:29:25PM +0200, Reimar D?ffinger wrote:
> >> >> >> > > On Sun, Jun 06, 2010 at 09:38:07PM +0200, Reinhard Tartler wrote:
> >> >> >> > > > In any case, find below the 'best' fix, that admittedly only works on
> >> >> >> > > > gnu platforms. Michael, please comment if you prefer the half fix that
> >> >> >> > > > fixes the issue on gcc/gas platforms (and doesn't regress on others) or
> >> >> >> > > > bumping major of libavformat.
> >> >> >> > > 
> >> >> >> > > How sure are we this is actually correct?
> >> >> >> > > The cases I could find documented (which only involve one library)
> >> >> >> > > also require changes to the version script.
> >> >> >> > > In case it was only one library, something like this:
> >> >> >> > > Index: libavcodec.v
> >> >> >> > > ===================================================================
> >> >> >> > > --- libavcodec.v        (revision 23508)
> >> >> >> > > +++ libavcodec.v        (working copy)
> >> >> >> > > @@ -1,3 +1,7 @@
> >> >> >> > > +LIBAVFORMAT_52 {
> >> >> >> > > +        global: av_init_packet;
> >> >> >> > > +};
> >> >> >> > >  LIBAVCODEC_$MAJOR {
> >> >> >> > > +        global: av_init_packet;
> >> >> >> > >          global: *;
> >> >> >> > > -};
> >> >> >> > > +} LIBAVFORMAT_52;
> >> >> >> > > 
> >> >> >> > > However here we have the problem that this would break e.g. on Solaris,
> >> >> >> > > since a symbol is not allowed to have multiple versions there.
> >> >> >> > 
> >> >> >> > +LIBAVFORMAT_52 {
> >> >> >> > +        global: av_init_packet;
> >> >> >> > +};
> >> >> >> >  LIBAVCODEC_$MAJOR {
> >> >> >> >          global: *;
> >> >> >> > -};
> >> >> >> > +} LIBAVFORMAT_52;
> >> >> >> > 
> >> >> >> > above does not work?
> >> >> >> 
> >> >> >> It does, but it does not do what I guess you want.
> >> >> >> It will only generate av_init_packet@@LIBAVFORMAT_52,
> >> >> >
> >> >> > yes
> >> >> >
> >> >> >> so it will still break compatibility to some previous versions.
> >> >> >
> >> >> > do you assume this or have you tested this?
> >> >> 
> >> >> 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

iam just saying that ldso has enough information to do this not that
there is a foobar at LIBC0VER in there litterally

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Why not whip the teacher when the pupil misbehaves? -- Diogenes of Sinope
-------------- 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/268e5489/attachment.pgp>