[FFmpeg-devel] [PATCH] restoring binary compatibility with ffmpeg 0.5
Wed Jun 9 02:57:31 CEST 2010
On Wed, Jun 09, 2010 at 01:02:22AM +0100, M?ns Rullg?rd wrote:
> Michael Niedermayer <michaelni at gmx.at> writes:
> >> > how do we move symbols in the future from lavf->lavc / lavc->lavu ?
> >> > this is something we have to do occasionally, and bumping soname is imo
> >> > not reasonable for this.
> >> I agree that it is pretty annoying, but I don't think it's unreasonable.
> > i guess we disagree here. I would consider fixing the problem where it is
> And where exactly is that?
I dont know yet, but if there is no way to move a symbol this is a shorcomming
that should be fixed not the extra work placed on every projects shoulders
> > more reasonable than inconvenciening all projects on linux
> That's not entirely accurate. A simple recompile is all that is
> required after a version bump like this.
A recompile is often not simple at all. Especially if thats a recompile of
100 packages that use a lib
> > either way, the little bit i can do to push the linkers to be fixed i will
> > do. That is i will block any and all major version bumps that would not be
> > required where the linker fixed.
> The linker will not be "fixed". In fact, I strongly doubt the linker
> is at fault at all here. Even if the linker were somehow faulty,
> fixing it would most likely wreak havoc on glibc, and as such it will
> simply never happen. Now please try to be reasonable.
I didnt even say the linker is at fault but for example
Changing the behavior for a case that was a failure to link that leads to a
hard failure is not going to break any working code.
Nor is changing a case that was a assertion failure.
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Democracy is the form of government in which you can choose your dictator
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: Digital signature
More information about the ffmpeg-devel