Xref: lysator.liu.se comp.sys.sun.wanted:1908 comp.sys.sun.admin:13142 comp.unix.solaris:6144
Path: lysator.liu.se!kth.se!sunic!mcsun!sun4nl!fwi.uva.nl!casper
From: casper@fwi.uva.nl (Casper H.S. Dik)
Newsgroups: comp.sys.sun.wanted,comp.sys.sun.admin,comp.unix.solaris
Subject: Re: Solaris 2.2 Automounter kills performance, FIXED
Date: 11 Sep 1993 17:11:20 GMT
Organization: FWI, University of Amsterdam
Lines: 85
Distribution: inet
Message-ID: <26t0ro$78p@mail.fwi.uva.nl>
References: <1993Sep8.221617.21008@protocol.com> <ric.747588039@updike> <26pk6c$oe3@mail.fwi.uva.nl> <ric.747678389@updike>
NNTP-Posting-Host: adam.fwi.uva.nl
Keywords: solaris

ric@updike.sri.com (Richard Steinberger) writes:

>OK.  But I'm still confused.  Why isn't -R/usr/openwin/lib working 
>properly?  [I left it in the sol2.h file because I figured that
>no every machine I installed emacs on would have the mit libs 
>where they are on MY system.]  libX11.so.4 is in /usr/openwin/lib and
>"dump -Lv /usr/local/bin/emacs" shows RPATH = /usr/openwin/lib.  So, is
>emacs looking for libX11.so.5.0 because that was the one it found
>in my LD_LIBRARY_PATH, but now it's only looking in /usr/openwin/lib?

In Solaris 2.x, teh library used at runtime must have the exact name
recorded at linkt time. libX11.so.4 and libX11.so.5.0 aren't the
same. The runtime linker will not substitute the one for
the other. (Not even if one was called *.so.5 and the otehr *.so.5.0)

>>>Second, SUNPro compilers seem to need LD_LIBRARY_PATH to link
>>>properly in many cases, especially f77.  It's unclear to me
>>>how to entirely eliminate LD_LIBRARY_PATH without causing
>>>other (worse) problems.  This is the value of LD_LIBRARY_PATH that I use:

>>You must be doing something wrong.

>But what?  LD_LIBRARY_PATH (regretably) serves TWO functions: 
>1) To provide a search path for ld to use in finding -lxxx (libraries)
>   [a link function] and

In Solaris 2.x you can split this function somewhat. By includiung
a semicolon in the path, the directories before the semicolon will
be used before the standard directories, those after the
semicoln will be searched after the all other directories.
Unfortunately, the runtime linker makes no such distinction.

If you need the LD_LIBRARY_PATH at link time, best
spoecify it oin the command line and start the part
you need at ru time with a semicolon. This makes ld
virtually ignore those directories at link time.

>2) To provide a run-time search path for shared libs.
>If I was doing something wrong, it must have been that I hadn't set
>up LD_RUN_PATH to point to /opt/SUNWspro/lib and /opt/SUNWspro/SC2.0.1
>(and elsewhere).  Does this seem reasonable?

Unfortunately, the -R option is not compatibile with the -L option.
the -R option takes a path as argument. It's the ``one and only''
runtime serach path. The side effect of this is that when you use
C++/Pascal/FORTRAN and X and you specify -R/where/X11/lives,
the SUNWspor lib doesn't get recorded. (This is a bug, I think).

Remedy: include /opt/SUNWspro/lib in the runtime path. I think this
latter path is the correct one, not SC2.0.1. This /opt/SUNWspro/lib
path is supposed to remain constant over time and contain all the
shared lib version. Note that you can ship those libs to your customers,
if I understaand the license correctly.


>Have I painted myself into a corner?  I have built some programs (e.g., emacs)
>that need LD_LIBRARY_PATH to execute.  But if I leave LD_LIBRARY_PATH
>set, I perpetuate the problem?  Is the only recourse to root out those
>programs that were linked when LD_LIBRARY_PATH was set and rebuild them
>with no LD_LIBRARY_PATH, but with LD_RUN_PATH set to something similar?
>WHY is SUN providing LD_LIBRARY_PATH if it causes programs to run
>so slowly (due to automounting)?

The build process isn't really affected by how your LD_LIBRARY_PATH
is set, at least not that much. But better start it with a ``;''.
an the effect is gone.

LD_LIBRARY_PATH for running executables is, in my view, only provided
to make incorrectly linked programs run. One possible solution would
be a program to set the RUN_PATH after linking.

>For now, I would like to set LD_RUN_PATH to what LD_LIBRARY_PATH is
>set to.  Does this make sense?  Then, next time I build emacs (and
>other "similar" pgms), be sure LD_LIBRARY_PATH is unset?

No. The -R option overrides the LD_RUN_PATH, so you must be very
careful. Just make sure it runs w/o an LD_LIBRARY_PATH.
The best way is to specify the right -R option.
I've never found that difficult.

(Not that this is why the R5 patch for Solaris uses
-R <X11lib>:$LD_RUN_PATH, so you can have an LD_RUN_PATH take
effect).

Casper