Subject: ldd
To: None <current-users@NetBSD.ORG>
From: der Mouse <mouse@Rodents.Montreal.QC.CA>
List: current-users
Date: 05/13/1998 18:20:44
I've encountered a bit of a deficiency in ldd.

I set up and installed X11R6.3.  Everything went fine, except that I
started seeing things like this:

[Sparkle] 5> xauth
/usr/libexec/ld.so: xauth: libXt.so.6.0: No such file or directory
[Sparkle] 6> 

ldd `which xauth` produced

[Sparkle] 6> ldd `which xauth`
/local/bin/xauth:
        -lXmu.6 => /local/.lib/X11-R6.3p1/libXmu.so.6.0 (0x10050000)
        -lXt.6 => /local/.lib/X11-R6.3p1/libXt.so.6.0 (0x10070000)
        -lX11.6 => /local/.lib/X11-R6.3p1/libX11.so.6.1 (0x100c0000)
        -lXext.6 => /local/.lib/X11-R6.3p1/libXext.so.6.3 (0x10170000)
        -lc.12 => /usr/lib/libc.so.12.26 (0x10180000)
        -lXt.6 => not found (0x0)
        -lX11.6 => not found (0x0)
[Sparkle] 7> 

This was aggravating and baffling, since I couldn't see either (a)
where the extra Xt.6 and X11.6 were coming from or (b) why it would
find Xt.6 and X11.6 just fine once and then report them "not found"
again later.

I eventually determined what was going on - specifically, Xmu.6 was
linked with -lXt -lX11, with -L but not -R, and I had no
LD_LIBRARY_PATH in the environment.  Setting LD_LIBRARY_PATH cured the
complaints, as did telling ldconfig to cache the relevant directory.  I
assume passing an appropriate -R when linking libXmu.so will do
likewise, though I haven't tried that yet.

The reason I'm writing is to remark that I shouldn't have had to deduce
this by experimentation.  ldd doesn't print nearly enough information;
there should have been some tool (ldd or otherwise) that could give me
a complete list of what xauth was linked with, including the -R
pathname and desired library version numbers, and nothing more.  There
also should have been something like ldd that not only printed out what
was found and what wasn't, but what was being looked for where and why,
output from which I could have seen why it wanted to load Xt.6 and
X11.6 twice, and why one attempt worked and the other didn't.  Even
with -f, I can't see any way to get ldd to do this.  While it is not
necessarily a problem that ldd can't, I wasn't able to find any tool
that could, which does strike me as a problem.

If there isn't one, would there be any interest in my producing one?  I
have something for SunOS that dumps out everything I know how to get
from the dynamic-linker data structures; it would probably be
relatively easy to do something similar for NetBSD, especially since
with NetBSD I can UTSL. :-)

					der Mouse

			       mouse@rodents.montreal.qc.ca
		     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B