becker@CS.ROCHESTER.EDU (Tim Becker) (01/12/90)
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.eduhaffley@cs.purdue.EDU (P Michael &) (01/12/90)
I noticed the same thing. It seems that ldconfig does NOT add the
directory to its search path. I did notice that one of the default
ldconfig directories is /usr/local/lib, so I just symbolicly linked
the lib files to this directory and now everything runs okay (after
executing ldconfig).
_ __ _ _ _ _ _ , _
' ) ) ' ) ) ) / // ' ) / /) /) //
/--' / / / o _. /_ __. _ // /--/ __. // // // _ __ ,
/ o / ' (_<_(__/ /_(_/|_</_</_ / (_(_/|_//__//__</_</_/ (_/_
/> /> /
</ </ '
P. Michael Haffley
haffley@iuvax.cs.indiana.edu
(ames,rutgers,pur-ee,att)!haffley