Can anyone shed more light on Doug's question below. Basically, svn binaries being installed such that they find their libs at a fixed location that cannot be overridden by LD_LIBRARY_PATH; is there a particular reason why this is so?
Doug Robinson wrote: > Julian Foad wrote: >> Doug Robinson wrote: >>> Looking at our build process it appears that we go out of our way to link >>> such that the Subversion binaries (e.g. "svn") are all bound with full >>> paths, for example: >>> >>> # ldd /usr/bin/svnadmin >>> libsvn_repos-1.so.0 => /usr/lib64/libsvn_repos-1.so.0 >> >> Hi, Doug. >> >> First I wrote the rest of this reply below. >> >> Then something made me look twice at 'ldd' and it appears to me that the >> interpretation may be wrong. >> >> I see the same sort of result as you for "ldd /usr/bin/svnadmin" but >> "objdump" shows: >> [[[ >> $ objdump -p /usr/bin/svnadmin | grep -C2 NEEDED >> >> Dynamic Section: >> NEEDED libsvn_repos-1.so.1 >> NEEDED libsvn_fs-1.so.1 >> NEEDED libsvn_delta-1.so.1 >> NEEDED libsvn_subr-1.so.1 >> NEEDED libapr-1.so.0 >> NEEDED libpthread.so.0 >> NEEDED libc.so.6 >> RPATH /usr/lib >> INIT 0x0000000000402ab8 >> >> ]]] > > Not sure what to make of that. Wish it were so. Empirically, the inability > to use LD_LIBRARY_PATH along with the output of ldd seems conclusive. > >> I'll leave the rest of the reply below in case it is of any use. >>> Since those paths are absolute, the LD_LIBRARY_PATH environment variable >>> won't help if the libraries are relocated: I found I needed to specify >>> them all with LD_PRELOAD as noted on NV-6950. And looking at the standard >>> SVN provided by some distros (e.g. SUSE 12), they've built them the same >>> way. >>> >>> My question is if you know the background as to this decision? Or was it >>> even a decision? >> I'm sure there's nothing specific to Subversion behind this. AFAIK that's >> just a typical way of installing dynamically linked executables. On further investigation -- e.g. these were helpful: http://blog.tremily.us/posts/rpath/ and https://wiki.debian.org/RpathIssue -- it seems "RPATH" in the executable is searched before $LD_LIBRARY_PATH and so any libs found in RPATH take precedence, whereas if one sets "RUNPATH" in the executable instead then $LD_LIBRARY_PATH overrides that. Of course different package distros can do things different ways, but should we be doing or enabling something different? > Ok, so there's no historical thought process that requires it? Might be good > to check with the other committers? Anyone want to comment on that perspective? >> The paths are written in at the 'install' phase, not any earlier in the >> build process. Variations are possible -- notably writing a lib search path >> called "rpath" into the executable which can be overridden at run time by >> LD_LIBRARY_PATH, or something like that. Fairly recently for some reason or >> other I read a bit about it and found there were a few variations on the >> theme, and it wasn't as simple as that and I don't have the complete scheme >> clear in my head. > > Never is "simple". I've done explicit things with linking and paths on other > (non-Linux) toolsets. So I "get it". And the docs are very spotty on Linux > as I've been doing research. > And then there's the fact that the LD_LIBRARY_PATH is explicitly disabled > when in the context of a set-id program. So dynamically finding your shared > library seems doomed in the most general case. > >> I half recall it may be possible to update the library path information in >> an already-installed executable. I think this was definitely possible for >> some kind of "rpath" included in the executable; not sure if it's possible >> to update the paths to individual .so files. > > I used to have such a tool in a past environment. It was WONDERFUL. I > haven't seen hide nor hair of one for Linux... that would be ideal. See the most-voted answer here: https://stackoverflow.com/questions/13769141/can-i-change-rpath-in-an-already-compiled-binary -- "patchelf"https://nixos.org/patchelf.html is available in the Ubuntu 18.04 repositories at least. >>> The background is that we have a customer who wants to be able to relocate >>> our stuff and one of the first things we'd need to do is to either rebuild >>> with a specific path just for them, or rebuild with just the leafnames so >>> taht LD_LIBRARY_PATH will work. >> >> The leafnames, plus perhaps some appropriate "rpath"-y configuration if you >> want a default location, sounds like the right way to go, unless there's >> already a tool that can modify . > > It's only the "right way to go" if the community does not have reason not to > do so. That's really why I asked. And that's the key question. Anyone? - Julian
