Bug 28191
| Summary: | rtld-elf ignores LD_LIBRARY_PATH | ||
|---|---|---|---|
| Product: | Base System | Reporter: | Chris BeHanna <behanna> |
| Component: | bin | Assignee: | John Polstra <jdp> |
| Status: | Closed FIXED | ||
| Severity: | Affects Only Me | CC: | jdp |
| Priority: | Normal | ||
| Version: | 4.3-STABLE | ||
| Hardware: | Any | ||
| OS: | Any | ||
Responsible Changed From-To: freebsd-bugs->jdp Rtld-elf is John's baby. Hi John, PR bin/28191 is assigned to you. It remains in the open state, but you appear to have provided an answer in PR bin/28406 that suggests the PR should be closed. It's not our policy to interfere with the state of assigned PRs without first asking the assignee. May I close this PR? Ciao, Sheldon. Sheldon Hearn wrote: > PR bin/28191 is assigned to you. It remains in the open state, but you > appear to have provided an answer in PR bin/28406 that suggests the PR > should be closed. [...] > May I close this PR? Hmm, maybe not. The standard I referred to in bin/28406 is pretty old -- from the SVR4 days. It now appears that Sun has switched to giving LD_LIBRARY_PATH precedence over the other elements of the search path. I'm inclined to make the same change, as requested in bin/28191. That has always made more sense to me, but I didn't want to go against whatever standards existed. I'll take care of it in the next few days. John I have fixed this problem in revision 1.56 of rtld.c. I will merge the fix into -stable in about 2 weeks. At that time I'll close this PR. John State Changed From-To: open->closed The fix for this has been merged into the RELENG_4 branch. |
The XFree86 4.1.0_4 port fails on this box when attempting to build the Type 1 fonts. In particular, this line fails: LD_LIBRARY_PATH=../../../exports/lib XFT_CONFIG=../../../lib/Xft/XftConfig ../../../exports/bin/xftcache . /usr/libexec/ld-elf.so.1: ../../../exports/bin/xftcache: Undefined symbol "XftDirSave" where `pwd` is /usr/ports/x11/XFree86-4/work/xc/programs/xftcache. According to rtld(1), LD_LIBRARY_PATH should supercede the default search path except for setuid and setgid executables, of which xftcache is neither. I verified this problem by running the command by hand and by doing "LD_LIBRARY_PATH=../../../exports/lib ldd xftcache". The output pointed to the installed /usr/X11R6/lib/libXft.so instead of the one within the XFree86 build tree and, indeed the installed libXft.so doesn't have the symbol XftDirSave, but the one in the build tree does. Note that ldconfig -r reveals an entry for libXft.so that does indeed point to /usr/X11R6/lib/libXft.so. That said, if I can't selectively override that by setting LD_LIBRARY_PATH on the command line, that's a big problem. From the comment from find_library(), I see that the executable's RPATH entry takes precedence over LD_LIBRARY_PATH. If that's the case, then how can LD_LIBRARY_PATH be used to force an executable to bootstrap itself from a build tree? Fix: Change find_library() to look in LD_LIBRARY_PATH before RPATH for non-setuid, non-setgid executables: If I completely misunderstand, please let me know, and I'll raise no fuss about closing this PR.--6aSk97htym4Ep3qFop4sigBxv57dhSjdz5i9cWbaLFChxxrS Content-Type: text/plain; name="file.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="file.diff" --- rtld.c Mon May 14 01:01:35 2001 +++ rtld.c.new Sat Jun 16 02:45:03 2001 @@ -803,8 +803,8 @@ dbg(" Searching for \"%s\"", name); if ((refobj != NULL && - (pathname = search_library_path(name, refobj->rpath)) != NULL) || (pathname = search_library_path(name, ld_library_path)) != NULL || + (pathname = search_library_path(name, refobj->rpath)) != NULL) || (pathname = search_library_path(name, gethints())) != NULL || (pathname = search_library_path(name, STANDARD_LIBRARY_PATH)) != NULL) return pathname; How-To-Repeat: Attempt to build XFree86 4.1.0_4 on an Athlon running 4.3-STABLE from the date indicated in uname -a, above.