Date: Mon, 3 May 1999 01:37:03 +0200 From: Bjoern Fischer <bfischer@Techfak.Uni-Bielefeld.DE> To: "Daniel C. Sobral" <dcs@newsguy.com> Cc: cvs-all@FreeBSD.ORG, John Polstra <jdp@polstra.com> Subject: Re: cvs commit: src/libexec/rtld-elf rtld.c Message-ID: <19990503013703.A280@broccoli.no-support.loc> In-Reply-To: <372BE410.87C7D5C7@newsguy.com>; from Daniel C. Sobral on Sun, May 02, 1999 at 02:35:12PM %2B0900 References: <XFMail.990501105137.jdp@polstra.com> <372BE410.87C7D5C7@newsguy.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, May 02, 1999 at 02:35:12PM +0900, Daniel C. Sobral wrote: > John Polstra wrote: > >=20 > > What do you think? In your opinion (totally unbiased, of course), > > does this argument hold water? >=20 > John, remember the initial complain message? "I have used X, Y and > Z, and I *hated* the way .RPATH worked." Moment, please. I have to set this right. First of all Solaris violates the spec, too: First LD_LIBRARY_PATH, then RPATH. I have seen this weird search order (RPATH, LD_LIBRARY_PATH) *only* in DEC OSF/1 and IRIX up till now. I complained about it and was told: "It conforms to the ELF spec." -- Oh. > Need I say more? Well, I will, just in case. :-) There is very > little that could be worse than breaking a standard that *is* used > by other Unixes. You initial suggestion would add a variable used > only by FreeBSD, yes, and it would *MAINTAIN COMPATIBILITY* not only > with the standard, but with other OSes. Think how much people will > hate you if you try to reverse the search path. :-) Oh no, we de-reverse it. The search path in the spec is reversed. ;-) Anyway, what do you think one has to change? If there's some .RPATH in the dynamic section, the maintainer seems to know what he's doing and he won't use LD_LIBRARY_PATH, but for hacking and testing. If not it won't hurt at all. Could you sketch an example for a situation that demonstrates the usefulness of a RPATH, LD_LIBRARY_PATH search order? All Unices (including FreeBSD) that use ELF added non-standard enhancements to the spec. Therefore incompatibility is just there. The ELF spec is neither complete nor fully worked out. E.g. library versioning is not covered at all: Every manufactor invented his own wheel. We can't maintain compatibility to other OSes here, since every manufactor interpretes the ELF spec individually.=20 There is very little that could be worse than breaking a standard: Following that standard blindly because two other Unices do. 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?19990503013703.A280>