From owner-cvs-all Fri May 7 6:52:40 1999 Delivered-To: cvs-all@freebsd.org Received: from frolic.no-support.loc (ppp36-192.hrz.uni-bielefeld.de [129.70.36.192]) by hub.freebsd.org (Postfix) with ESMTP id 1369414DC6 for ; Fri, 7 May 1999 06:52:18 -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 PAA02056; Fri, 7 May 1999 15:39:56 +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 PAA00495; Fri, 7 May 1999 15:39:56 +0200 (CEST) (envelope-from bjoern@no-support.loc) Date: Fri, 7 May 1999 15:39:55 +0200 To: John Polstra Cc: cvs-all@FreeBSD.ORG Subject: Re: cvs commit: src/libexec/rtld-elf rtld.c Message-ID: <19990507153955.A300@broccoli.no-support.loc> References: <19990430020203.A971@broccoli.no-support.loc> 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: ; from John Polstra on Sat, May 01, 1999 at 10:51:37AM -0700 Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk Hello John, as I said I contacted SCO -- they are currently hosting the System V ABI specification -- and got the reply attached below. They also seem to favorize the `Sun approach' ;-) There is mentioned a development of a new version of the ABI. Maybe FreeBSD should try to get involved into that development. The only developer representing a free OS is Varesearch at the moment. Bj=F6rn ----- Forwarded message from Dion Johnson ----- [...] > Dion, >=20 > this is okay for me. Here's my problem: >=20 > While administrating many Unices (BSD taste and SysV/AT&T taste) I ran > into problems on IRIX and Digital Unix. I was about to upgrade some > shared libraries `in place' and moved the old ones somewhere else. > Due to the lack of source, I wasn't able to recompile/relink a few > executables that needed the old libraries. I decided to use a > quick'n'dirty solution until I would have the sources again: I set > LD_LIBRARY_PATH to the directory, where I moved the old libs to. > And -- to my surprise -- it didn't worked at all. I realized that the > runtime linker first looked in the .RPATH of the executable and *after* > that in LD_LIBRARY_PATH. So the new libraries were used instead of > the old ones. >=20 > After discussing this with other admins I considered that strange > behaviour as a bug. After contacting SGI and DEC I was told that this > search order pretty conformes with the ELF spec and I was even more > surprised. >=20 > I looked through the spec and examined how different OSs that are using > ELF implement it. Some, e.g. Solaris, violate it and give > LD_LIBRARY_PATH precedence over .RPATH. >=20 > It always seemed naturally to me that first LD_LIBRARY_PATH and > after that .RPATH will be searched. That's how it worked all the time. > But maybe I'm wrong. Generally, when an executable is properly built > and installed .RPATH is used to resolve all shared library needs -- > not only due to efficiency. LD_LIBRARY_PATH is for testing/debugging > or for `quick'n'dirty' solutions. So LD_LIBRARY_PATH must have > precedence over .RPATH, IMHO. >=20 > Please, could you explain >=20 > why does the ELF spec give .RPATH precedence over LD_LIBRARY_PATH? >=20 > Thank you. >=20 > Regards, >=20 > Bjvrn Fischer >=20 >=20 Bjoern, This is what I hear from our engineers: The ABI has always specified that RPATH takes precedence over LD_LIBRARY_PATH. Sun has always chosen to ignore that requirement. The original rationale was that the developer of the application knows more about where his/her libraries should live than an individual user. LD_LIBRARY_PATH, being an environment variable, is a fairly blunt instrument. I actually think the Sun approach makes more sense. =20 In the new version of the ABI currently being developed by several of the IA-64 OS vendors: Intel, IBM, SGI, Sun, SCO, HP and Varesearch, representing Linux, we are probably going to agree to a new dynamic section entry, DT_RUNPATH. This entry will be allowed in both executables and shared objects. It will have lower precedence than LD_LIBRARY_PATH. This is still in the discussion stage, however. Dion L. Johnson II - The Santa Cruz Operation, Inc. dionj@sco= .com Developer Tools and Technical Customers' Advocate. 400 Encinal St. Santa Cruz, CA 95061 FAX: 831-427-5417 Voice: 831-427-= 7565 ----- End forwarded message ----- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message