Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!usc!snorkelwacker!bloom-beacon!CS.ROCHESTER.EDU!becker
From: becker@CS.ROCHESTER.EDU (Tim Becker)
Newsgroups: comp.windows.x
Subject: Sun Shared Library Problems - new info (I think)
Message-ID: <9001111641.AA13483@mango.cs.rochester.edu>
Date: 11 Jan 90 16:41:15 GMT
Sender: daemon@athena.mit.edu (Mr Background)
Organization: The Internet
Lines: 46

I want to install R4 in a non-standard location.  I've followed the
discussion and proposed solutions to the "can't find libXmu.so.xxx"
problems.  So when I built R4 and installed it, I didn't figure I'd
have a problem.  I ran ldconfig setting my (non-standard) library
path, but my R4 programs wouldn't run (saying they can't find the X
libraries).  Worse yet, "ldd xterm" (for example) came up blank --
nothing printed out telling me the location of *any* libraries.

I wrote a test program to figure things out.  Here's what I've
learned:

The library location specified at load time (from cc or ld with the -L
option) tells ld.so (the dynamic loader) where to look for a library
at run time.  In my test case, I wrote a library and small program -
linking in the library using "cc -o play play.o -L. -ltest".  I can
run this program when my pwd is the current directory, but not from
anywhere else.  -- even with ldconfig set to that directory!  If I
change the cc option "-L." to "-L<full path to pwd>", it runs fine.

Then I wondered about LD_LIBRARY_PATH.  It comes real close to solving
the above problem.  I can link with a relative path ("-L.") and
override this by setting LD_LIBRARY_PATH to <full path to pwd>.  Now I
can run my test program from anywhere.

One problem -- if the program is setuid to someone other than you,
LD_LIBRARY_PATH is ignored by ld.so.  So, this program won't be able
to find his library.  I don't know of any way around this.

How does this relate to R4? --  All the clients are linked with -L
pointing to the relative path of the X libraries in the build tree.
So, running ldconfig telling it the final (non-standard) resting place
of your X libraries won't work.  Having every X user set
LD_LIBRARY_PATH to this library location almost works.  Xterm is
setuid root - so they can't get xterm to run.  (Besides, I'm not sure
I want to burden my users with this LD_LIBRARY_PATH stuff).

I'm starting to think that the right solution is to get the client
Imakefile's to list -L<install library path> in addition to the
-L<build tree library path>.  I think this will work.

Comments?

(BTW, I'm running SunOS4.0.3 on a SparcStation 1).

Tim Becker.
becker@cs.rochester.edu