From owner-freebsd-hackers Sat Jan 6 08:15:28 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id IAA02180 for hackers-outgoing; Sat, 6 Jan 1996 08:15:28 -0800 (PST) Received: from expo.x.org (expo.x.org [198.112.45.11]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id IAA02172 for ; Sat, 6 Jan 1996 08:15:24 -0800 (PST) Received: from exalt.x.org by expo.x.org id AA11145; Sat, 6 Jan 96 11:14:52 -0500 Received: from localhost by exalt.x.org id QAA14121; Sat, 6 Jan 1996 16:14:51 GMT Message-Id: <199601061614.QAA14121@exalt.x.org> To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) Cc: hackers@freefall.FreeBSD.org Subject: Re: Demand loading (Re: FreeBSD, Zappa & PCI) In-Reply-To: Your message of Sat, 06 Jan 1996 16:15:31 EDT. <199601061515.QAA14865@uriah.heep.sax.de> Organization: X Consortium Date: Sat, 06 Jan 1996 11:14:50 EDT From: "Kaleb S. KEITHLEY" Sender: owner-hackers@FreeBSD.ORG Precedence: bulk > > > > > > I'd also be keen to get rid of ldconfig > > > > and ld.so.cache. > > > > > > Why? > > > > > > I've been missing them on SysV. (For configuration purposes, let the > > > possible performance gain from a shorter lookup time alone.) > > > > > > > In SVR4 (or Digital Unix nee OSF/1) you set the RPATH in the executable > > to dictate where to look for shared libs if the shared libs aren't in the > > "usual" place; completely obviating the need for ldconfig and ld.so.cache. > > Packages put the libraries where ever they want, the program knows where > > to find them. You don't need hints like ldconfig and ld.so.cache. > > Who puts the RPATH into the executable? At least, simply linking it > e.g. against an X11 library with ld doesn't put it there. When you have ELF, ld can put it there. > In my case, > it was an application that has been linked against some X11 libs but > that is regularly started via inetd, so there wasn't an easy way for > tweaking the environment. The latter is not the normal way to go > anyway, think of setuid binaries. Setuid *root* binaries ignore LD_LIBRARY_PATH, even with ELF. > My only solution was to symlink the X cruft into /usr/lib. Not very > exciting. This isn't necessary if you've ldconfig'd /usr/X11R6/lib into the ld.so.cache? > What about binaries where i want to shuffle the shared libs around > later? Yuck. :-) With ELF it's reasonably easy to write a utility to rewrite the RPATH in a program if you really wanted to move its libraries around. > (E.g., they are linked against Motif, and i'd like to keep my > copy of Motif in a separate subtree?) Keeping Motif (source?) in a separate subtree is one thing. You install the libraries somewhere, right? /usr/X11R6/lib? You've added /usr/X11R6/lib to your ld.so.cache, right? So with ELF, each application has it's own ld.so.cache, except that it's called RPATH, and it's stored in each application instead of the global /etc/ld.so.cache. Actually the whole RPATH thing is optional. The run-time loader knows how to find well known directories, like /lib, /usr/lib, and maybe /usr/local/lib too. Only applications that want libraries that aren't in the well known places need to use the RPATH. > You haven't convinced me yet that the SysV solution is better than > ld.so.hints. I've given up long ago of trying to convince the people on -hackers of anything. :-) > No, i'm not defending BSD since it's just BSD, but > ldconfig used to be one of the tools i love in BSD. It gives the > administrator a fine-grain control about the location of shared > libraries, without fiddling with the environment. Other than the fact that ld.so.cache is a minor security hole. Okay, any sysadmin worth their salt isn't going to add world writable directories to the ld.so.cache, but you never know. I don't know how many people I've had to tell about ldconfig and the ld.so.cache. Most people shipping BSD systems are finally smart enough to put /usr/X11R6/lib into their ldconfig/ld.so.cache by default now, which is fine until someone (like me) uses a different ProjectRoot in their X build, which is when that strategy falls apart. At least I know to go fix my /etc/rc.local to build my ld.so.cache correctly. :-) All in all it'd be nicer (IMHO) if I didn't even have to muck with ldconfig and ld.so.cache. -- Kaleb KEITHLEY