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> <26pk6c$oe3@mail.fwi.uva.nl> 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 :$LD_RUN_PATH, so you can have an LD_RUN_PATH take effect). Casper