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

[Måns Rullgård]

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.

-- 
M?ns Rullg?rd
mans at mansr.com