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
Received on 2018-09-28 16:42:24 CEST