[FFmpeg-devel] Upgrade Trouble
Sat Dec 12 00:09:55 CET 2009
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.
> 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.
> 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.
> 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
> * 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.
>> In parallel, I asked the Debian glibc maintainers for their opinion. I
>> was pointed to the -Bsymbolic ld flag, which, alters the symbol lookup
>> behavior of the runtime linker as well.
> If i understand you correctly that would make libavformat quite a bit bigger
> namely by the size of libavcodec and libavutil. Iam not sure if this is
> a good idea.
Okay, then let's forget that idea.
> 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.
I guess I'll just go ahead and start working on the plan with
introducing symbol versioning.
Reinhard Tartler, KeyID 945348A4
More information about the ffmpeg-devel