[FFmpeg-devel] Upgrade Trouble

[Michael Niedermayer]

On Sat, Dec 05, 2009 at 01:41:59PM +0100, Reinhard Tartler wrote:
> 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.

I think we misunderstand each other somehow here.
What i meant to say is that an application will by default without versioning
always be linked to the version it depends on. There is no preferance for
newer versions, the preferance is rather "closer to the application" in the
dependancy tree. This way its libavcodec that will see symbols from the wrong
version. [this behavior is required by the ELF spec]

that is an old app, with new but same soname libavcodec and that libavcodec
depening on a new soname libavutil -> libavcodec will get all symbols from the
old libavutil when they are duplicate, only new symbols will be bound to the
new soname libavutil.
Thats deeply broken misdesign but its what ELF requires.


[...]
> >> 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?

if we end up with versioning on lavf+lavc then yes.


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

Because it seemed that this is the minimal change that solves the
problem and because that way the lavc->lavf code move issue does not
arrise
iam not opposed to have versioning added to all if doing so has an
advantage, ATM though i just see a small disadvantage in it.


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

no, but iam sure its possible to find them by looking at what
ffmpeg/mplayer/vlc use that doesnt have such prefixes

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

The real ebay dictionary, page 3
"Rare item" - "Common item with rare defect or maybe just a lie"
"Professional" - "'Toy' made in china, not functional except as doorstop"
"Experts will know" - "The seller hopes you are not an expert"
-------------- 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/20091205/291a6cab/attachment.pgp>