bo@hubcap.clemson.edu (Bo Slaughter) (08/14/90)
Howdy. After compiling several X-Windows applications, I get the following error message: ld.so: call to undefined procedure __GetHostname from 0xf779c984 I have looked everywhere for this procedure, but can't seem to locate it. Can someone (anyone?) point out to me the error of my ways? Bo Slaughter -- +--------------------------------------------------------------+ | Bo Slaughter bo@gumby.eng.clemson.edu | | (803)656-2721 "I'm gumby.eng.clemson.edu dammit." | +--------------------------------------------------------------+
murthy@algron.cs.cornell.edu (Chet Murthy) (08/14/90)
bo@hubcap.clemson.edu (Bo Slaughter) writes: >Howdy. >After compiling several X-Windows applications, I get the following >error message: >ld.so: call to undefined procedure __GetHostname from 0xf779c984 >I have looked everywhere for this procedure, but can't seem to locate >it. Can someone (anyone?) point out to me the error of my ways? I get this on some of the Sparcstations here (but not on others). It has to do with the shared library support in SUNos, and I just switch to another machine for compiling. The proper fix is to re-install the X libraries - I suspect that some library is out-of-date. --chet--
jef@well.sf.ca.us (Jef Poskanzer) (08/15/90)
Many problems with Sun's shared libraries can be solved by remembering
to run ldconfig (as root) after making any changes. Other problems can
be avoided by remembering to increment the version numbers every time
you install a new library, whether you have compiled any applications
with that library or not. But I have yet to solve this one: when I
try to run some of my X applications I get "ld.so: libXaw.so.4: not found".
There are two strange things about this. One, version "4" doesn't exist
and has never existed; I have versions "4.0", "4.3", and "4.4", but
no "4". Two, when I run the exact same program under trace, the bloody
thing works perfectly.
Sun's shared libraries suck.
---
Jef
Jef Poskanzer jef@well.sf.ca.us {ucbvax, apple, hplabs}!well!jef
"Talk is cheap because supply exceeds demand." -- Laura Creightonguy@auspex.auspex.com (Guy Harris) (08/16/90)
>But I have yet to solve this one: when I try to run some of my X >applications I get "ld.so: libXaw.so.4: not found". >There are two strange things about this. One, version "4" doesn't exist >and has never existed; I have versions "4.0", "4.3", and "4.4", but >no "4". The message is less than clear. Perhaps it should say something such as "ld.so: libXaw: major version number 4 not found" to indicate that it's not looking for "libXaw.so.4", but for anything that matches "libXaw.so.4.*". The idea is that the major version number should change if the library changes in such a way that binaries linked with the old version will not work with the new version, so that the program will only link up with the old version (which, of course, you have to keep around). The minor version number should change if the library changes in wuch a way that binaries linked with the new version won't (or may not, anyway) work with the old one, but binaries linked with the old version will still work with the new one, so that programs linked with the old version can pick up the new one, but programs linked with the new one will, at best, pick up the old one under duress. >Two, when I run the exact same program under trace, the bloody >thing works perfectly. Is the program in question set-UID? If so, is "libXaw" installed somewhere other than "/usr/lib" or "/usr/local/lib"? If so, this isn't surprising. The run-time loader will *not* search outside the standard directories for shared libraries if the effective and real user IDs (or, I hope, group IDs) don't match, so as to forestall fraud. When a set-UID program is run under "trace" - or anything else that uses "ptrace()" - the set-UIDness is ignored, again to forestall fraud.