[FFmpeg-devel] Upgrade Trouble

Michael Niedermayer michaelni
Fri Dec 11 15:20:14 CET 2009

On Fri, Dec 11, 2009 at 03:08:03PM +0100, Michael Niedermayer wrote:
> On Fri, Dec 11, 2009 at 09:19:31AM +0100, Reinhard Tartler wrote:
> > 
> > Michael Niedermayer <michaelni at gmx.at> writes:
> > 
> > > Are you sure its not worthwhile to fix the linker? This dependancy & conflict
> > > dance has to be done each time a project wants to add versioning.
> > > The linker should do the following (and it does not)
> > > 1. Prefer a symbol with matching version over an unversioned symbol.
> > >    Not just pick the first that does not have a mismatching version.
> > > 2. do a breadth first search from the object where a symbol is referenced
> > >    Not a breadth first search from the application.
> > > 3. Not fail assertions.
> > 
> > As indicated above, I've now done more research on your idea. I've
> > talked to a colleague at my department, who has programmed an linker for
> > embedded systems, and fetched Levine's excellent book "Linkers and
> > Loaders" from the library.
> > 
> > Let's recapitulate roughly what the runtime linker does at load time:
> > Conceptually, the runtime linker builds at bootstrap phase of a program
> > a global symbol table containing all symbols of all DSO the application
> > is linked to. This symbol table is only conceptually global. In
> > practice, there are actually two (one for code, one for data), and there
> > are actually tables for each and every library. At bootstrap phase,
> > these tables are combined in a linked list. (there are a bit more
> > optimizations going on here like lazy lookups for function, but that
> > doesn't matter for this discussion, for details please see Levine's
> > book, chapter 10.3, "Loading a Dynamically Linked Program" and chapter
> > 10.4, "Lazy Procedure Linking with the PLT").
> > 
> > What you now propose is to introduce "hierarchic symbol tables", as my
> > colleague called it. I would rather call that "introducing namespace"
> > that are created on load time of a library. This way the runtime linker
> > would have to obey the library in which the search for symbol it was
> > started.
> > 
> > I think this is not a good idea for a few reasons:
> > 
> >  - you could of course change the list in which the symbol tables are
> >    linked to a graph to implement the "hierarchic symbol table" conecpt,
> >    but this increases the complexity of the runtime linker considerably!
> The alternative puts the complexity on all the package maintainers who
> maintain libs that can be referenced more than once in an applications
> dependancy tree.
> I always am in favor of fixing the root cause of problems not to let
> everyone have to work around it, that being a O(1) vs. O(N) thing.
> But then iam also not really expecting that the linker will be changed,
> though it really would be nice if a lib or application could enable
> such behavior for its dependancies ...

also ive just realized theres another global solution
always enable versioning by the soname for all libs that dont specify a
version script, that way the problems should never arrise.
Why does this all of a sudden remind me of the PT_GNU_STACK default of
"please hack me" that 99% of everyone want&have to override

Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Why not whip the teacher when the pupil misbehaves? -- Diogenes of Sinope
-------------- 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/20091211/2b0fc2cb/attachment.pgp>

More information about the ffmpeg-devel mailing list