Date: Sun, 27 Jan 2002 17:15:07 +0100 From: Bjoern Fischer <bfischer@Techfak.Uni-Bielefeld.DE> To: "Alexey V. Neyman" <alex.neyman@auriga.ru> Cc: John Polstra <jdp@FreeBSD.ORG>, cvs-committers@FreeBSD.ORG, cvs-all@FreeBSD.ORG Subject: Re: cvs commit: src/libexec/rtld-elf rtld.c Message-ID: <20020127161507.GA431@frolic.no-support.loc> In-Reply-To: <02012711582605.01347@vagabond.auriga.ru> References: <02012711582605.01347@vagabond.auriga.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
Hello Alexey, hello John, > Are you sure this change is right? As my copy of ELF specifications=20 > from Intel's Tool Interface Standards states, the linker should have=20 > the following order of searching (pg. 2-15): >=20 > %%% > - First, the dynamic array tag DT_RPATH may give a string that holds a=20 > list of directories separated by colons (:). For example, the string=20 > /home/dir/lib:/home/dir2/lib: tells the dynamic linker to search first=20 > the directory /home/dir/lib, then /home/dir2/lib and then the current=20 > directory to find dependencies. >=20 > - Second, a variable called LD_LIBRARY_PATH in the process environment=20 > may hold a list of directories as above, optionally followed by a=20 > semicolon and another directory list. >=20 > [skip] >=20 > All LD_LIBRARY_PATH directories are searched after those from DT_RPATH. > %%% >=20 > I'm almost sure this change should be reverted. Please also see PR=20 > #28406 and the commit log for revision 1.21 of=20 > src/libexec/rtld-elf/rtld.c. You are right about this. The search order as proposed in the latest ELF spec is: 1. DT_RPATH 2. LD_LIBRARY_PATH 3. DT_RUNPATH (4a. ldconfig hints) 4. systems default path (/usr/lib, etc.) But in practise it has been proven that searching LD_LIBRARY_PATH *after* DT_RPATH is very uncomfortable since it may prevent the intentional functionality of LD_LIBRARY_PATH in certain situations. (Ask the libtool maintainer, he will tell things...) Some ELF implementations (eg. SunOS) simply broke the spec and searched LD_LIBRARY_PATH before DT_RPATH, which was much more rational. I had contacted an employee of SCO who was working on the next version of the ELF spec that time. He agreed that the spec was a bit unhandy in the way it handles the search order. In the next version (should be out by now) a new dynamic tag DT_RUNPATH will be included that has almost the same functionality as DT_RPATH *and* will be searched *after* LD_LIBRARY_PATH. So the preferred way to resolve this problem should be to modify the compile time linker and/or it's frontends to use DT_RUNPATH in favor to DT_RPATH, when -R or -rpath is given. Does that violate POLA? Hmm, then new flags may be implemented e.g. -runpath. Personally I can live with the comitted new (old) search order. In this case, I think, it does harm less to break the spec than to cripple LD_LIBRARY_PATH. -Bj=F6rn 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?20020127161507.GA431>