Date: Sat, 06 Jan 1996 14:49:25 EDT From: "Kaleb S. KEITHLEY" <kaleb@x.org> To: hackers@freefall.FreeBSD.org Subject: Re: Demand loading (Re: FreeBSD, Zappa & PCI) Message-ID: <199601061949.TAA17491@exalt.x.org> In-Reply-To: Your message of Sat, 06 Jan 1996 19:15:39 EDT. <199601061815.TAA15371@uriah.heep.sax.de>
next in thread | previous in thread | raw e-mail | index | archive | help
> As Kaleb S. KEITHLEY wrote: > > > > > > > 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. > > It was ELF. I wrote about my troubles on a SystemV. (Unixware, > actually. This machine has not yet been converted to FreeBSD, > although the operator of the box would really like to have this > happen. :) Oh, now we're talking about Unixware, not FreeBSD??? Unixware is SVR4, not SYSV. > > Setuid *root* binaries ignore LD_LIBRARY_PATH, even with ELF. > > Does this imply that e.g. setgid kmem binaries under SysV do _not_ > ignore LD_*_PATH, so i could abuse them? It wasn't meant to be an exhaustive list. > > > > 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? > > Yup, Unixware doesn't have an ld.so.cache. Then I still don't understand why you had a problem. If you have X/Motif- based apps that came with Unixware, they use the libs that are already in /usr/lib. If you used XFree86 X-based apps, they're built with RPATH and the run-time loader knows how to find the libraries the app needs. > > > 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. > > Ick. > > > > (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. > > So i have to parse my entire directory tree to find out all binaries > that dynamically link the Motif lib? And i have to modify each of > them manually? (I don't speak about things that will be recompiled > from source, i think about a set of working binaries.) Why are you moving the libraries around? If you're going to move the libraries around, that's the penalty. The lesson is, don't move the libraries. If you're moving the libraries, particularly X libraries, does that also mean you're moving app-defaults files and all the other X paraphenalia around? Are you going to force all your users to set an X_FILE_SEARCH_PATH environment variable in order to find app-defaults files, localization files, Compose maps, and what have you? > Btw., Lasermoon's ugly SWiM package did also use their own ld.so.cache > in the mwm they're shipping: they have hard-linked it to > /usr/X11R6/lib/libXm.so.2.0.0 -- even though they ship the system so > that it installs into /usr/X386 (and i have forced the installation > into /usr/Motif). You can imagine how i liked this. :-] Is this on FreeBSD again, or on Unixware? What does it mean to say they use their own ld.so.cache? Why are you moving the libraries? > > > 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. > > Exactly. The ld.so.cache is intented to list a set of trustable > libraries. As does RPATH. > (Btw., you are always implying that ld.so.cache would > contain _directories_. This is not true. It lists every and all > shared lib to be used.) Sigh, this doesn't change anything. You give a list of directories to ldconfig, which constructs an ld.so.cache with a list of shared libs to use; every shared library on the whole system. If I have two of libXm.so.2.0.0 on my system, which one do I get with ldconfig/ld.so.cache, the SWiM library in /usr/X386 or the one I built from source in /usr/X11R6/lib? It depends on which one I specified first with ldconfig, right? With ELF, you link with a set of libraries, you supply an RPATH, at run-time the loader looks for the library, first in the RPATH, then in the well known places. I can have programs that use libXm.so.2.0.0 in two (or more) different places because they each have their own RPATH. At run-time it's a quicker search of a shorter list, and it's more flexible. Go learn about the ELF link editor and run-time loader work. There is a reason why every major UNIX vendor (and Linux too) have moved or are moving to ELF. Next thing you'll be telling me I don't want a malloc that agressively sbrks memory back to the system. I'm the customer damn it. What I want is not right or wrong, it's just what I want. If you don't want to give it to me, I'm sure I can find someone else who will! Linux perhaps? Linux has ELF, Linux has gnumalloc in libc. Gee, Linux looks mighty damn good. Or maybe I'll graft the Linux ELF support into FreeBSD, and since you all have Not-Invented-Here syndrome I'll be forced to release KalebBSD. :-) -- Kaleb "I'm the customer, damn it" KEITHLEY
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199601061949.TAA17491>