Ubuntu's multisearch surprise [LWN.net]

Ubuntu's multisearch surprise

Posted Aug 10, 2009 11:21 UTC (Mon) by mjthayer (guest, #39183)
In reply to: Ubuntu's multisearch surprise by ringerc
Parent article: Ubuntu's multisearch surprise

That is more a consequence of problems in the *nix linking model, where all shared objects land in a global namespace. It is desirable for a few things like the C library, but for most shared objects it causes more problems than it solves. It would be so nice if build-time linking had the equivalent of dlopen's RTLD_LOCAL flag. I think this should even work without breaking LD_PRELOAD, as preloaded libraries would still be loaded as "RTLD_GLOBAL" libraries, so would still override the subsequent RTLD_LOCAL loaded ones.

to post comments

Ubuntu's multisearch surprise

Posted Aug 10, 2009 18:53 UTC (Mon) by nix (subscriber, #2304) [Link] (3 responses)

It can still be a problem even if you have RTLD_LOCAL, if objects managed
by one version of a shared library end up being passed to another version
in the same address space, or if both of them are contending trying to
manage some shared resource (classic examples, both from libc: wtmp and
the malloc arena).

What RTLD_LOCAL fixes is the 'whoops, symbol name clashes between totally
different shared libraries because they dared to use a symbol with the
same name' problem.

Ubuntu's multisearch surprise

Posted Aug 10, 2009 19:08 UTC (Mon) by mjthayer (guest, #39183) [Link] (2 responses)

Right, those are the "few things like the C library" that I meant: things which are global to the application by nature. Having a link-time RTLD_LOCAL would not be a panacea, and would be bound to introduce a few problems of its own. On the other hand, since it would be an opt-in thing for each shared object linked into any ELF binary, the problems could be sorted out incrementally.

Ubuntu's multisearch surprise

Posted Aug 11, 2009 9:22 UTC (Tue) by ringerc (subscriber, #3071) [Link] (1 responses)

It affects more than just a few C library details. In particular, `static' variables can be a problem. Link-time RTLD_LOCAL appears to imply the presence of multiple instances of the library executable mapped into memory, or at least multiple copies of their rw segments. Otherwise you'd encounter funky behaviour differences depending on whether two unrelated libs happened to link to the same versions of some 3rd lib or different versions of it.

That makes it hard when libraries at the same linkage "level" (say libh and libi) want to pass around objects that may, either overtly or behind the scenes, rely on shared static data (library-internal caches or the like) in a library (say libj) they both use. Of course, they can't pass libj objects across library boundaries anyway unless they know they're using at least a compatible version of libj, since their layout might and/or meaning not be compatible, so they may as well share the same instance of libj's rw data segment too, as if it were RTLD_GLOBAL.

This sort of thing is very common in things like application frameworks (qt/gtk/etc) and plugins.

I seem to remember that Mac OS X tackles this by defaulting to something like RTLD_LOCAL linkage, but allowing objects to specify global linkage instead. That's vague memory only though, and I haven't hunted down any documentation to confirm it.

Ubuntu's multisearch surprise

Posted Aug 11, 2009 9:34 UTC (Tue) by mjthayer (guest, #39183) [Link]

Still, I would have thought that whoever is linking in the shared object would have a good idea at link time whether or not they needed to share objects from that object with others. To take your example, if libh and libi share objects created by libj, then they should both know to link in libj into the global scope - that is, not to opt in to local linkage for it.