This is the mail archive of the
libc-alpha@sources.redhat.com
mailing list for the glibc project.
Possible ld.so modifications
- From: Mike Hearn <mike at theoretic dot com>
- To: libc-alpha at sources dot redhat dot com
- Date: 17 Dec 2002 19:50:47 +0000
- Subject: Possible ld.so modifications
- Organization:
Hi,
My question is whether it'd be possible to write (and get accepted) a
patch to allow multiple major versions of the same library to be loaded
into an address space at once by altering the linker semantics so a
global symbol table isn't used.
The problem we have is we are trying to build distro neutral packages
(autopackage.org) and one issue is that if I have app1 which is compiled
against say libpng3 and libSDL, and the distro linked libSDL against
libpng2, the app will at best segfault on startup due to (we think)
symbol clashes.
There doesn't seem to be any reason why it wouldn't be possible to
symbol lookup to only check the symbol tables of libraries the object
that's currently being processed is linked against, so libSDL would
correctly link against libpng3 and the app could separately use libpng2
(this is just an example).
Would such a patch be feasable? From looking at the source it seems the
global symbol table is just a hangover from the days of static linking
and internally it maintains separate symbol tables. I seriously doubt
anything relies on this behaviour, who would write a lib that doesn't
link against what it needs and assumes the app that uses it does
instead?
Finally, if we did somehow produce such a patch, would it stand a chance
of being accepted into the mainline or would we have to ship the new
linker separately and edit the INTERPRETER elf header to point to it?
thanks -mike
--
Mike Hearn <mike@theoretic.com>