Re: glibc hackers?

> HOWEVER - (and I know this will cause some grief initially! :-) - how
> about getting the linker to "hash" (can't remember the C++ word...) the
> reference so that a reference stored at link time contains BOTH the
> library soname and the symbol name.

The word you're thinking of is mangling.

Binding a symbol to a specific library is what -Bdirect semantics do
iirc, but main focus is on -Bgroup: the problem is that some libs expect
things to be overriden etc. Such a thing also wouldn't solve symbol
conflicts, with -Bgroup conflicts outside the group are solved, leaving
you with conflicts inside the group right?

Problem is, headers on Linux don't specify a particular library to
import things from in the way that they do on say Windows. It's
implicitly a part of the linkers job to fix that.

Anyway, although having to globally namespace all your symbols is a
PITA, I don't think the cost of rewriting almost every library header
out there is worth it to be honest, it's simpler to just rename symbols
as and when they collide (or use symbol versions).

The good thing about these linker changes is that they involve minimal
changes to the actual code itself, you can simply recompile (maybe even
not needing that, but i expect a recompile would be needed to be on the
safe side).

> Not quite sure how we proceed from there. But it guarantees that if we
> have glibc2.1 and glibc2.2 and glibc2.3 all present on the user's
> system, the runtime linker will at least *try* to use the same library
> that the packager used at compile time.

glibc is a special case, because it never breaks backwards compatability
at the library level, it uses symbol versioning to effectively rename
each symbol instead of just bumping the major version (as is common with
most libs). So if you have glibc 2.3, you also effectively have 2.2 and
2.1

There are other problems with binding each symbol tightly to the
library, like it might break quite a lot of code out there that relies
on LD_PRELOAD.

Eventually more widespread use of direct linking might be a good idea,
but it's a very long term thing, for now grouping solves most of the
problems we're seeing with library collisions.

thanks -mike