Re: Possible ld.so modifications

[Mike Hearn <mike at theoretic dot com>]

> If you want to avoid problems due to incompatible
> versions of the same binary hammer some knowledge into the maintainers
> of these packages.

I thought the whole point of libtool versioning was that it was possible
to cleanly break binary compatability when necessary without making
things break though? Surely maintaining backwards compatability between
major versions goes against that idea? I may be mistaken, this is a new
area to me.

> They are at fault at it is not acceptable to punish everybody with a
> more complex and slower and incompatible dynamic linker just because
> some people don't get their acts together.

Could you explain why it's be more complex, slower and incompatible?
As the linker already maintains separate tables for each object, and knows
which libs each object is linked against, the changes internally wouldn't
be huge (I think), and I don't see how it'd affect fixup speed. Obviously 
I'm no linker expert, but I'm interested in learning more.

Oh, finally, does anything actually depend on having a global symbol table?
Some simple experiments we just tried (may be flawed) seemed to suggest you
can't use symbols without the -l flags to make it link against the library,
which also suggests you can't just assume symbols will be present because they
were imported somewhere else in the link tree.

> If necessary fork the packages and maintain version with symbol
> versioning or similar methods yourself.

I don't understand why symbol versioning is the solution here... it'd be
quite hard to make gtk2 abi compatable with gtk1 for instance, even
though I guess it's feasable that an app could implicitly import both if
some library along the chain was able to pop up a gui for instance.

Incompatability - I can see this would change the semantics of ELF
internally to Linux (i'm not suggesting this change should be global to
all unixes, perhaps a compile time option?) but would it cause any other
compatability issues?

many thanks -mike
-- 
Mike Hearn <mike@theoretic.com>