[FFmpeg-devel] Upgrade Trouble

[Michael Niedermayer]

On Wed, Dec 02, 2009 at 11:13:21PM +0100, Reinhard Tartler wrote:
> Michael Niedermayer <michaelni at gmx.at> writes:
> 
> >> How can the problem described in my mail avoided in an *elegant* way?
> >
> > The problem disapears if the linker wouldnt shadow symbols but rather
> > provide each piece of code with what it declared to depend on.
> 
> This sounds pretty much like symbol versioning, as discussed in the
> "other" subthread.
> 
> Or did I misunderstand you and I miss something?

yes, what i suggest is that the linker behaves sanely without bandaids.
what it does is a breadth first search from the application, what it
should do is a breadth first search from the object where a symbol is
used.
iam no expert in all these corner cases of shared lib ABI compatibility
but then its clear the others in this thread arent either.
Possibly RTLD_DEEPBIND could solve the problem. Drepper is quite vocal
on arguing against it which is a sign that this might be the right direction.

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.

Of course iam not against other solutions if a linker/loader based solution
is not possible. symbol versioning seems like an option, though here some
extra work is needed to manually patch up the corners like symbols that
have been moved from lavf -> lavc.

Bumping tha soname of a lib that has not changed its interface is something
id like to avoid.
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.


Also there is another aspect that should be mentioned, debians dependancy
system is buggy if it does not detect this.
I mean if the linker/loader used by debian cannot handle 2 libs with
different major abi versions linked together it should not allow this
situation to arise for any application.

something like:
lavu=123
conflicts_when_loaded_togeher: lavu!=123

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

It is dangerous to be right in matters on which the established authorities
are wrong. -- Voltaire
-------------- 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/20091203/2a790304/attachment.pgp>