This is the mail archive of the libc-alpha@sources.redhat.com mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Possible ld.so modifications


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>


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]