ld.so error: Undefined symbol: _XtInherit

Milton D Miller milton at ecn.purdue.edu
Sun Oct 21 04:24:49 AEST 1990


In article <850 at ucthpx.UUCP> gram at staff.UUCP (Graham Wheeler) writes:
>I too have had this exact same error. I did a fgrep on the output of nm applied
>to the Xt library and found that the symbol *did* exist in the library and was
>defined. Running ranlib didn't help. Eventually I gave up (I posted the problem
>but never received any responses).

Somebody posted this  a while back, and I have verified it worked for
me the time I needed it.

The short answer is if you don't use Xt in your program, then don't link
with it if you are using shared libraries.

My understanding of what is happening (someone feel free to correct me):  

[Note: I will refer to the C function names here, add another _
to get the symbol names reported by ld -- milton]

_XtInherit is a stub c function in the unshared library that calls
__XtInherit in the shared library.  This stub function is there to
avoid some problem with data initialization (the function pointer
is used to initialize fields in several data structures), at least
if I am reading the comments in the code correctly (the stub function
is in shared.c, I forget which file has the real function).

When you link your application (which doesn't use Xt) no reference is
made to _XtInherit, so the unshared library segment is not included
by the linker.  However, the shared object name is still placed in
the list of libraries to be accessed at runtime by ld.so.  It is in
the shared object that the references to _XtInherit are being 
generated, hence the error.

I suppose another solution would be to explicitly tell the loader
to add _XtInherit to the list of undefined symbols, but this would
just create an unnecessarly large executable.


milton

Milton D. Miller II,    ECN Student consultant,    Purdue University
milton at ecn.purdue.edu                                  pur-ee!milton



More information about the Comp.lang.c mailing list