[FFmpeg-devel] Upgrade Trouble

[Reinhard Tartler]

Michael Niedermayer <michaelni at gmx.at> writes:

> The way i understand it the application is linked to the correct libavutil
> rather libavcodec is linked to the wrong one.

No, I want to avoid recompiling applications that are linked against the
'old' libavutil. So it is rather the other way round.

>> > Either way, ffmpeg isnt the only thing that seems to have been hit by this
>> > A->B1,C1 B1->C2 symbol shadowing bug so i really think that a generic
>> > solution at the linker/loader level would be best. It might solve this
>> > problem once and for all.
>> 
>> Correct. other libraries that got hit by this problem started
>> implementing proper symbol versioning.  Prominent examples for this
>> include the gnu libc and libdb (berkely db).  A more complete explanation
>> why symbol versioning helps in the situation of is explained in Dreppers
>> DSO howto[1], section "3.3 ABI Versioning", p.35f.
>
> i dont like drepper

My neither, but this doesn't help here either.  You can also have a look
at the sun manuals. The symbol versioning idea is basically taken from
sun. Drepper extended it by allowing multiple versions of the same
symbol to coexist in the very same DSO. This allows to do API changes
while retaining the old ABI. NB: This is not the problem I'm currently
looking at.

>> Indeed. The approach to statically prefix the SONAME to each symbol is
>> trivial to implement, but leads to the situation that moving symbols
>> from lavf to lavc effectively results in an ABI break that would require
>> an SONAME bump.  This might be an acceptable compromise, but can only be
>> avoided by using a more sophisticated approach for symbol versioning.
>
> For moving symbols between lavf->lavc we would need to keep the symbol with
> the old version in lavf until the next bump but that would have to be under
> some kind of #if ELF_SO_VERSIONING otherwise we could end up with 2 symbols
> of the same name that might have some sideeffects

Yes, that would indeed by an option if we go the "each symbol gets the
'full SONAME' as version tag" route.

Do you want me to implement this?

>> > I dont think lavc/f exports parts of lavu, if they do that would need a
>> > soname bump of course.
>> > That said iam open to all solutions if the nicer ones are exhausted, the
>> > problem is real and a solution needed.
>> 
>> I'm happy to read that you take this problem seriously.  I'd be willing
>> to help with implementing symbol versioning in FFmpeg, if you can give
>> me hints what kind of work would be helpful.
>
> If we do have to use versioning, then it seems changing libavutil to use
> it would solve the problem at hand, that also would avoid any problems
> with lavc->lavf moves for the moment.

Why just libavutil, and not each and every library in FFmpeg?

> also symbols not starting with av/ff should be local (though this is a
> seperate issue and will need some work in the form of exceptions being
> added due to historic symbols which didnt had these prefixes but need to be
> exported)

Do you have a list of these?

-- 
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4