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

[Michael Niedermayer]

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

[...]
-- 
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/6de7f176/attachment.pgp>