jorice@maths.tcd.ie (Jonathan Rice) (06/27/90)
In <7557@ccncsu.ColoState.EDU> thorson@typhoon.atmos.colostate.edu (Bill Thorson) writes: >I am trying to build Metafont with the X11 interface. The problem I >am running into is that it is looking for XtInherit and can't find >it. Can anyone tell me what library that can be found in? I've had a similar but possibly unrelated problem. First of all, by "XtInherit" I take it that you mean the _XtInherit procedure, which is used as the test value to determine if a widget class inherits a widget field value from its superclass or not. This is described on Page 21 of the X11R4 X Toolkit Intrinsics manual. The procedure is defined in mit/lib/Xt/Initialize.c and is eventually built into the Xt library libXt.a. Now to my problem, which has to do with the _XtInherit beastie and SunOS shared libraries. I'm using SunOS 4.0.3 on a Sparcstation1 and gcc 1.36. I'm running X11R4 and using the Athena widget set, both of which were compiled using cc. SYMPTOM: At run-time, ld.so complains ld.so: Undefined symbol: __XtInherit If I use static libXt.a, no problems. Links fine. Now, from a cursory inspection of the X source, it seems that this is to do with some tricking around with names so that _XtInherit has a consistent value throughout all shared copies. _XtInherit is one of several routines which have static stub versions defined for them in mit/lib/Xt/sharedlib.c. When using the value of _XtInherit, you therefore get this single static value. When *calling* _XtInherit, however, the stub routine in turn calls the original (now shared) version which has been renamed to __XtInherit by a #define, which carries out the original error-printing function. That's the way it *should* work, as far as I can see. So why can't ld.so find the shared version? Here's what I get when I run nm on shared and static versions of Xt to see what's actually there: libXt.a:Initialize.o:0000002c T __XtInherit libXt.sa.4.0:sharedlib.o:00000000 T __XtInherit libXt.sa.4.0:sharedlib.o: U ___XtInherit libXt.so.4.0:0000c19c T ___XtInherit That *looks* correct to me. Any suggestions? *------------------------------------------------------------------------------* | Jonathan Rice | Email: jorice@cs.tcd.ie | He was a common fly | |------------------------| Tel.: (01) 772941 x2156 | With a taste for fashion | | Computer Science Dept. | Fax: (01) 772204 | They were thrown together | | Trinity College |-------------------------| In a heat of passion | | Dublin 2, | woof /\___/ | - "Human Fly", | | Ireland. | /| |\ | The Horseflies | *------------------------------------------------------------------------------*
dbd@marbury.gba.nyu.edu (Daniel B Dobkin) (06/30/90)
|>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