[FFmpeg-devel] Upgrade Trouble

Michael Niedermayer michaelni
Sun Dec 6 20:03:32 CET 2009


On Sun, Dec 06, 2009 at 11:50:21AM +0200, Uoti Urpala wrote:
> On Sat, 2009-12-05 at 17:55 +0100, Michael Niedermayer wrote:
> > On Sat, Dec 05, 2009 at 01:41:59PM +0100, Reinhard Tartler wrote:
> > > Michael Niedermayer <michaelni at gmx.at> writes:
> > > > 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.
> 
> As I said in an earlier mail introducing symbol versioning requires
> rebuilding depending applications/libraries,

This is not correct, you are wrong.


> and it's better to do that
> for all FFmpeg libraries in one go.

What is better will be decided by the ffmpeg developers and of course
Reinhard who actually does the work and who might run into problems
with one approuch and thus find the other preferable at that point,
now he did already run into a problem with stuff moved from lavc->lavf
maybe there are other problems with the alternative, we will see ...

Ive no strong preferrance to either choice, but as said your oppinion
is not a variable that will be considered.
If you have technical arguments they are welcome, for facts i can read
the specs or source, they are more reliable than what you present as
if they where facts.


> Symbol versioning _will_ be needed
> for lavc/lavf too at latest at the next version bump (as there are other
> libraries depending on them),

maybe but even if it is so that is so since many years and no reason to
introduce versioning in lavc in the same revission as lavu.


> and introducing the new versions smoothly
> requires that everything has been built with versioning support _before_
> the new lavc/lavf versions appear.

Again this is not correct, applications never need to be rebuild

old soname libavutil needs a rebuild due to a bug in the gnu linker
which causes a versioned dependancy to be linked to a unversioned
definition even though a correctly versioned definiiton is available.
[this bug should be reported]
also its in theory possible to workaround this though .symver directives
but the only way i do know ATM to do this would become too messy, requireing
1 such directive for each symbol ...

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

Republics decline into democracies and democracies degenerate into
despotisms. -- Aristotle
-------------- 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/20091206/d469b630/attachment.pgp>



More information about the ffmpeg-devel mailing list