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

[Måns Rullgård]

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
>> >> >> 
>> >> >> 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

I still don't understand what makes you want to say that.

> 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.

That is _not_ how symbol versioning works or was ever intended to
work.  The versions are _per symbol_ and quite independent of any
overall "library version".

> 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

Not true.  It will require *exactly* ver1 of foo and *exactly* ver2 of
bar.  Symbol versions are not library versions.

> 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.

No, it doesn't.  All the version script does is assign versions to
symbols in the particular library that is being created.  If a later
edition of the same library adds ver2 of foo, the script will of
course be updated to reflect this.  The version script is not
available to users of the library, so anything you think you might
infer from the script is simply irrelevant.

> 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.

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