chucks@SNE42N.ORL.MMC.COM (11/14/90)
Original question: When I run a X program that I wrote I get the error ld.so symbol not found __XtInherit Well it seems that a lot of people on SUNS running 4.0.3 and 4.1 with and without the openwin libraries are having the same problem. One workaround is to link the Xt library statically. This causes the size of the executable to increase dramatically. This done with either -Bstatic -lXt -Bdynamic or /usr/lib/libXt.a in your link line. The problem has to do with the sun shared libraries and the need to link __XtInherit statically. The problem does not always manifest itself as I have compiled and run hundreds of X clients with no problems. So, can someone that really understands the shared vs. static libraries explain what is happening here. I received 20+ requests for the answer, so it seems to be a recurring problem with no true fix. Malcolm Strickland chucks@iplmail.orl.mmc.com Martin Marietta Electronic Systems 407-356-5909
etaylor@wilkins.iaims.bcm.tmc.edu (Eric Taylor) (11/14/90)
You are, of course, removing all .o files before remaking with the SUNSHLIB and SHARECODE options are you not? _XtInherit is defined to be __XtInherit in the SHARED LIBARY version. _XtInherit is an actual routine in the static version. Be absolutely sure that no .o turds are left when you to the 2 compilations. -- Eric Taylor Baylor College of Medicine etaylor@wilkins.bmc.tmc.edu (713) 798-3776
db@sunbim.be (Danny Backx) (11/15/90)
> So, can someone that really understands the shared vs. static libraries > explain what is happening here. Sure. I'll start at the beginning. Sun's shared libraries have 2 parts. One is called the SO part, and is truly shared, the other is the SA part, and is not shared. You can find these things as e.g. -rw-r--r-- 1 root 7996 Feb 8 1990 /usr/lib/libc.sa.1.5 -rwxr-xr-x 1 root 516096 Feb 8 1990 /usr/lib/libc.so.1.5 The shared part contains everything you don't write to. The unshared part contains the rest. This rest is essentially [read this thoroughly] : initialized global variables, except if they are read-only. There are several gothas here. 1. You need to compile the library with option -pic (or -PIC), because the SO part gets linked into the program on addresses unknown in advance. 2. If your program somewhere contains a comparison to a routine name, the routine being in the shared library, then you better be real careful about this. (This is less valid if you as a user link with a shared library, but certainly true if you write a shared library. I.e. if, in the library code, you do this type of comparison, then the routine must be put in the SA part.) 3. This one is the one that is bugging you. I think it is a /bin/ld bug, Sun probably thinks differently. You need to have an unresolved reference to one of the symbols in the SA part in your program. In practice, this means that YOUR PROGRAM must have a reference to _XtInherit in it. If you don't have this, then ld will forget to link in the SA part. Now if you write a decent program (i.e. one that initializes the toolkit), then you will automatically have this. If, however, your program is weird in the sense that it uses certain Xt routines, without ever calling XtInitialize or something similar, then you have a problem. A nice example of this is OSF's uil compiler. It uses XtMalloc and related stuff all the time, but it doesn't open any connection to an X server. So what you need to do in order to compile this successfully with shared library is put in a reference to _XtInherit. You can do this by putting a call to XtInitialize() in the main program, for instance after the exit() statement. (Right, you don't even need to call it. Just make sure it's in there.) Two more notes : 1. Don't ask me how Sun makes sure that /lib/libc.sa.* always gets linked into your program. Maybe they hacked up ld ? 2. The people who bought our Motif 1.1 package know how I resolve these problems for them. Danny Backx BIM Networks System Engineer E-Mail: db@sunbim.be (or uunet!mcsun!ub4b!sunbim!db) Telephone: +32(2)759.59.25 Fax : +32(2)759.47.95 Postal Mail : Danny Backx BIM Kwikstraat 4 3078 Everberg Belgium
jordan@morgan.COM (Jordan Hayes) (11/15/90)
When I run a X program that I wrote I get the error ld.so symbol not found __XtInherit [ Should this go into FAQ? ] Here's what is happening. There is a kludge in libXt to get Sun shared libraries to work, which involves this __XtInherit business. The reason for it is that you can't share a function that is both called and compared -- _XtInherit is the only function that I know of in libXt that does this. i.e., if (wc->manager_class.translations == (XtTranslations)_XtInherit) The trick is to find some function that is *guaranteed* to be called in an application and put the definition of _XtInherit into the same .o file ... XtToolkitInitialize is the right choice for this, since (theoretically) it should be called before any of the other Intrinsics functions, thus ensuring that _XtInherit will get referenced, and thus, loaded. Bottom line: one of two things is happening: 1) You aren't calling XtToolkitInitialize() anywhere. -- uil in motif 1.1 has this problem -- Solution: make sure you call XtToolkitInitialize(); all of the standard *Initialize() functions do this, so unless you are doing something before initializing the Intrinsics, you should be okay. 2) You don't *need* to call XtToolkitInitialize() in your program. This can happen if you are writing only in Xlib, or using a toolkit that is not Xt-intrinsics based. -- XView doesn't use the Intrinsics, for example -- Solution: take the library -lXt out of your link command. ----- The non-solution of linking -Bstatic "works" because this is an artifact of shared libraries. Don't bother -- one of the other two ways above shold work. /jordan