Path: utzoo!attcan!uunet!tut.cis.ohio-state.edu!zaphod.mps.ohio-state.edu!usc!apple!snorkelwacker!mintaka!yale!cmcl2!exchange!marbury.gba.nyu.edu!dbd
From: dbd@marbury.gba.nyu.edu (Daniel B Dobkin)
Newsgroups: comp.windows.x
Subject: Re: Can't fine XtInherit
Message-ID: <3523@exchange.GBA.NYU.EDU>
Date: 29 Jun 90 21:52:25 GMT
References: <7557@ccncsu.ColoState.EDU> <1990Jun27.165544.4413@maths.tcd.ie>
Sender: usenet@exchange.GBA.NYU.EDU
Reply-To: dbd@marbury.gba.nyu.edu (Daniel B Dobkin)
Lines: 29


|>SYMPTOM: At run-time, ld.so complains
|>		ld.so: Undefined symbol: __XtInherit
|>	If I use static libXt.a, no problems. Links fine.
|>

I've seen this, too.  The trick is to touch /usr/lib/libXt.sa.  Then when you
link, you'll see a warning that the table of contents is out of date: ignore
it (don't follow its advice).  Here's what seems to be happening:

When you link against shared libraries, ld also checks for a corresponding
data segment and resolves references from the user program from this archive
first; references within the shared libraries are NOT resolved at link time. 
Thus, the problem occurs when something in the static segment (in this case,
_XtInherit) is referenced by something in the shared library; because the
linker never saw the reference, it never attempted to resolve it and the
routine was never linked in.  When ld thinks the table of contents is out of
date, it seems to link in the entire library (which in this case consists
only of _XtInherit, which is what we want).

The only "solution" I can think of is to include yet another stub somewhere
that never gets called, but which does call _XtInherit.   Yuck.  (I suppose
I could bury it in an include somewhere, but really....)  Can anyone suggest
an alternative?


\dbd
Stern School of Business
New York University