[FFmpeg-devel] Upgrade Trouble

[Reinhard Tartler]

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
that. [1]

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


[1] http://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html#id293373
-- 
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4