From owner-cvs-all Sun May 2 16:36:57 1999 Delivered-To: cvs-all@freebsd.org Received: from frolic.no-support.loc (ppp39-85.hrz.uni-bielefeld.de [129.70.39.85]) by hub.freebsd.org (Postfix) with ESMTP id E527B14DD2 for ; Sun, 2 May 1999 16:36:36 -0700 (PDT) (envelope-from bfischer@Techfak.Uni-Bielefeld.DE) Received: from broccoli.no-support.loc (broccoli.no-support.loc [192.168.43.99]) by frolic.no-support.loc (8.9.3/8.9.3) with ESMTP id BAA00673; Mon, 3 May 1999 01:37:04 +0200 (CEST) (envelope-from bjoern@no-support.loc) From: Bjoern Fischer Received: (from bjoern@localhost) by broccoli.no-support.loc (8.9.3/8.9.3) id BAA00400; Mon, 3 May 1999 01:37:04 +0200 (CEST) (envelope-from bjoern@no-support.loc) Date: Mon, 3 May 1999 01:37:03 +0200 To: "Daniel C. Sobral" Cc: cvs-all@FreeBSD.ORG, John Polstra Subject: Re: cvs commit: src/libexec/rtld-elf rtld.c Message-ID: <19990503013703.A280@broccoli.no-support.loc> References: <372BE410.87C7D5C7@newsguy.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Mailer: Mutt 0.95.5i In-Reply-To: <372BE410.87C7D5C7@newsguy.com>; from Daniel C. Sobral on Sun, May 02, 1999 at 02:35:12PM +0900 Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk 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