In message <1050325956.17589.63.camel@nagasaki.ihack.net>, you write: 

-> On Mon, 2003-04-14 at 04:40, Christopher SEKIYA wrote:
-> > On Sun, Apr 13, 2003 at 12:55:27PM -0400, Rafal Boni wrote:
-> > 
-> > > I'm not sure which binutils versions generate the correct output accordi
-> ng
-> > > to the comment and which ones don't -- other than the fact that it appea
-> rs
-> > > that the current in-tree one does not).
-> > 
-> > After a quick test, I agree.  Removing the "broken" conditional (per the f
-> irst
-> > hunk of your patch) indicates that SUPPORT_OLD_BROKEN_LD should actually
-> > be SUPPORT_NEW_BROKEN_LD :)
-> 
-> I think y'all need to read the comments in there to understand what's
-> going on a bit.  That code had the "broken" conditional because it
-> entirely defeats lazy binding, and so is not very attractive for general
-> use.

Right, I do realize it's defeating lazy binding, but I'd rather have a
runtime linker that works right than one that is fast but doesn't work
correctly 8-)

In the perfect world, all we'd need to do is find a better heuristic to
catch those -- I'm guessing your heuristic for setting "broken" was a
good one to identify old-old libraries which had the problem I found
back in October, 2001 but not so well for identifying the newer issue
of "pointers to functions resolved incorrectly".

ISTM that to find this new b0rken-ness you found, one would have to
figure out the "broken" state based on the main object, and pass that
in to the fixup handlers for the shared objects...

-> The problem you're running into (which I documented a while back, and
-> asked for help from some MIPS binutils g00r00s) has to do with the use
-> of function pointers.  IIRC, function pointers in MIPS executables are
-> being resolved directly to the function, if the function exists in the
-> executable, but function pointers in shared libraries are being resolved
-> to the library's PLT slot.  This is causing the pointers to compare
-> incorrectly, which in turn causes some random lossage (e.g. libXt
-> doesn't work so well in some cases).

Right, this matches my experience... But it seems to be that even our
newest toolchain still generates this b0rken state and ld.elf_so does
not catch it.

Do you actually have (ie, have you played with) a version of binutils
that *doesn't* exhibit this problem?  Has it been fixed in more recent
binutils versions?

[...rest snipped re: the more-obviously incorrect bit of my patch...]

--rafal

----
Rafal Boni                                                     rafal@attbi.com
  We are all worms.  But I do believe I am a glowworm.  -- Winston Churchill