Date: Fri, 30 Apr 1999 02:02:04 +0200 From: Bjoern Fischer <bfischer@Techfak.Uni-Bielefeld.DE> To: John Polstra <jdp@polstra.com> Cc: cvs-all@FreeBSD.ORG Subject: Re: cvs commit: src/libexec/rtld-elf rtld.c Message-ID: <19990430020203.A971@broccoli.no-support.loc> In-Reply-To: <XFMail.990429092410.jdp@polstra.com>; from John Polstra on Thu, Apr 29, 1999 at 09:24:10AM -0700 References: <19990429162225.A267@broccoli.no-support.loc> <XFMail.990429092410.jdp@polstra.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Apr 29, 1999 at 09:24:10AM -0700, John Polstra wrote: [...] > > All in all, what is LD_LIBRARY_PATH for? It's for hacking and > > testing, for quick'n'dirty solutions. For linking binaries that may > > be installed on a system and will be used for a longer time you use > > RPATH. So I think giving RPATH precedence over LD_LIBRARY_PATH is a > > bad idea, although it conforms with ELF. >=20 > I think it's important to follow the spec as much as we can. But I > agree that you're describing a real problem. Maybe we can solve > that problem in a different way that doesn't violate the ELF spec. >=20 > How about if the dynamic linker also honored a second environment > variable, say, LD_LIBRARY_PATH0 or LD_LIBRARY_PREPATH or > LD_LIBRARY_PATH_OVERRIDE. (Somebody please think of a decent name for > it!) This variable would take priority over the RPATH. So the > search order would become: >=20 > LD_LIBRARY_PATH0 > RPATH in the shared object > LD_LIBRARY_PATH > ldconfig hints > /usr/lib >=20 > Would that be acceptable? Hello John, This would help the local FreeBSD administrator to override RPATH for testing and quick'n'dirty solutions. But it would add a FreeBSD specific environment variable. E.g. build Tcl/Tk. Ok, concerning shared libraries this is an example from hell, but it illustrates the problem: If you say `make test' after compiling, LD_LIBRARY_PATH is set to the build dir. But the new `tclsh' or `wish' won't use the new libraries but the old (already installed) ones due to the RPATH. One has to change it to LD_LIBRARY_PATH_OVERRIDE before `make test'. LD_LIBRARY_PATH is commonly known (and abused). Introducing a new environment variable may lead to confusion. There are many traps giving a new environment variable the functionality that is commonly expected from LD_LIBRARY_PATH. What would be harmed if we violate the specification and give LD_LIBRARY_PATH precedence over RPATH? I just don't like `Follow the specs, no matter whether it's good or bad'. If such a violation is out of the question, LD_LIBRARY_PATH_OVERRIDE would be, well, would be a way. And don't think of a decent name for it, `LD_LIBRARY_PATH_OVERRIDE' or better `LD_LIBRARY_RPATH_OVERRIDE' is quite okay: It is long. It suggests "I know, this is quick'n'dirty, better I'll do it `The Right Way(TM)'". If you like, I'll write a section for the linker man page illustrating why LD_LIBRARY_RPATH_OVERRIDE and/or LD_LIBRARY_PATH is quick'n'dirty, where it does make sense to use it anyway and why one should use RPATH instead. Phew, that was easy. Tomorrow I'll convince SGI and Digital/Compaq to fix their runtime linkers and after that I'll find that guy who had the idea to give RPATH precedence over LD_LIBRARY_PATH and to put it into the ELF standard. On the other hand SGI and Digital/Compaq are so busy inventing new logos and names for their operating systems... Bj=F6rn --=20 -----BEGIN GEEK CODE BLOCK----- GCS d--(+) s++: a- C+++(-) UB++++OSI++++$ P+++(-) L+++(--) !E W- N+ o>+ K- !w !O !M !V PS++ PE- PGP++ t+++ !5 X++ tv- b+++ D++ G e+ h-- y+=20 ------END GEEK CODE BLOCK------ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19990430020203.A971>