[FFmpeg-devel] Upgrade Trouble

Michael Niedermayer michaelni
Sat Dec 12 14:39:08 CET 2009


On Sat, Dec 12, 2009 at 12:09:55AM +0100, Reinhard Tartler wrote:
> Michael Niedermayer <michaelni at gmx.at> writes:
> >> So all in all, I'm now pretty sure that changing the existing linker is
> >> an option for solving the problem at hand.
> >
> > was that really what you wanted to write? ;)
> 
> err, of course not. I wanted to write: "I'm now pretty sure that
> changing the existing linker is *NOT* an *appropriate* option for
> solving the problem at hand."
> 
> > also your above arguments only address the second point ive raised,
> > Point 1 and 3 still stand, i guess you arent arguing that failing with
> > an assertion is correct behavior?
> 
> I've not addressed points 1 and 3 because I haven't managed (yet) to
> reproduce the symptoms. With the testcase I've written earlier, I've
> encountered not an assertion failure, but a failure to find a symbol. So
> I think you're trying something more obscure than I'm doing.



gcc -shared -fPIC -c libA0.c -o libA0.o
ld -shared libA0.o -o libA0.so

gcc -shared -fPIC -c libA1.c -o libA1.o
ld -shared libA1.o -o libA1.so

gcc -shared -fPIC -c libB0.c -o libB0.o
ld -shared libB0.o -o libB0.so -L. -lA0

gcc app.c -o app -L. -lB0 -lA0

./app
#libA0
#B libB0
#libA0
#libA0
#        (correct)

gcc -shared -fPIC -c libA1.c -o libA1.o
ld -shared --version-script libA1.v libA1.o -o libA1.so

gcc -shared -fPIC -c libB0.c -o libB0.o
ld -shared libB0.o -o libB0.so -L. -lA1

./app
#libA0
#B libB0
#libA0
#libA0
#        (libB0 is linked by the linker to the wrong lib here)


gcc -shared -fPIC -c libA0.c -o libA0.o
ld -shared --version-script libA0.v libA0.o -o libA0.so

./app
#libA0
#B libB0
#libA1
#libA0 
#        (correct)


gcc app.c -o app -L. -lB0 -lA0

./app
#libA0
#B libB0
#libA1
#libA0 
#        (correct)

gcc -shared -fPIC -c libA0.c -o libA0.o
ld -shared libA0.o -o libA0.so

./app
#./app: ./libA0.so: no version information available (required by ./app)
#Inconsistency detected by ld.so: do-lookup.h: 115: check_match: Assertion `version->filename == ((void *)0) || ! _dl_name_match_p (version->filename, map)' failed!


gcc -shared -fPIC -c libA0.c -o libA0.o
ld -shared --version-script libA0.v libA0.o -o libA0.so

gcc -shared -fPIC -c libA1.c -o libA1.o
ld -shared libA1.o -o libA1.so

./app
#./app: ./libA1.so: no version information available (required by ./libB0.so)
#libA0
#B libB0
#Inconsistency detected by ld.so: do-lookup.h: 115: check_match: Assertion `version->filename == ((void *)0) || ! _dl_name_match_p (version->filename, map)' failed!

------
libA0.v
LIBA0VER
{
 global:
    *;
};

libA1.v
LIBA1VER
{
 global:
    *;
};

libA0.c
#include <stdio.h>
void functA(){
    printf("libA0\n");
}

libA1.c
#include <stdio.h>
void functA(){
    printf("libA1\n");
}

#include <stdio.h>

libB0.c
void functB(){
    printf("B libB0\n");
    functA();
}

app.c
#include <stdio.h>
int main(){
    functA();
    functB();
    functA();
    return 0;
}
-----------




> 
> > Or that prefering an unversioned symbols over a versioned one
> > with matching version is correct?
> 
> I think that when introducing symbol versioning all applications need
> to be rebuilt in order to pick up the new versioned symbols and the
> problem doesn't arise in the first place.

An application that is not rebuild links to the correct symbols
A not rebuilt lib can link to the wrong symbols, you can rebuild all libs
But does this ensure that the user doesnt upgrade just a subset?


> 
> > If one combines these 2 you even end up with a funnier case where a
> > unversioned symbol is always prefered over the correct versioned one
> > but the removial of the never used versioned one leads to hard failure
> 
> I don't see how this can become a problem in practice. If I upload a new
> FFmpeg 0.5 package with versioned symbols, it will instantly replace all
> copies of FFmpeg 0.5 libraries with unversioned symbols.

on the debian servers sure but if an application gets rebuild against the
new versioned libs cant the user upgrade the application without upgrading
the lib? (the soname didnt change here, does something still add a dependancy
to ensure this upgrade?)


> 
> > Now if  1+3  where fixed without the "hierarchic symbol tables"
> > as your colleague called my point 2 that still would be a huge simplification
> > for distro packagers.
> > The reasons should be obvious
> >
> > * currently introducing versioning one needs to make sure that no application
> >   that has been build with the new versioned lib can end up being linked to
> >   the older lib without versioning but otherwise 100% identical ABI.
> >   Because ld.so goes bye bye with assert(0) in that case
> 
> That's why we have a documented and recommended migration strategy for
> that. [1]

That guide also says all libs depending on one that changed the soname must
themself change the soname (thats just a ridiculously extreem way to work
around linker bugs).
You didnt plan to do that, but what matters more, is the rest of the guide
still correct if one doesnt do that?


> 
> > * The other issue that would be fixed is that if a versioned symbol is
> >   preferably bound to a symbol with matching version and a unversioned
> >   symbol is preferably bound to a unversioned symbol.
> >   Then you could just introduce a new libavutil.50 with versioning enabled
> >   and thats it, it would work. Now you need a complicated net of conflicts
> >   to prevent any application to end up with a libavutil with and without
> >   versioning because the linker can mis-bind the symbols in this case.
> 
> The Debian migration strategy addresses that.
[...]

> >
> > If you really want an "alternative" to versioning and to fixing the linker
> > that would be simply #including an header that appended _50 to all libavutil
> > symbols. This wont assert(0) and it wont miss-bind symbols to the wrong
> > version so it should avoid most of the conflict&dependancy dance. But one
> > thing it cant do, you cant add _49 to the existing lib obviously.
> > Iam not sure if this is a good idea but at least considering how poor
> > the gnu linker handles versioning simply hard renaming symbols seems quite a
> > bit more robust.
> 
> Well, this is more or less introducing symbol versioning by hand in the
> source code, AFAIUI.

Yes but it avoid bugs 1 & 3 in the linker (aka it actually works).


> 
> I guess I'll just go ahead and start working on the plan with
> introducing symbol versioning.

fine with me

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

Awnsering whenever a program halts or runs forever is
On a turing machine, in general impossible (turings halting problem).
On any real computer, always possible as a real computer has a finite number
of states N, and will either halt in less than N cycles or never halt.
-------------- 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/20091212/a9beb0fb/attachment.pgp>



More information about the ffmpeg-devel mailing list