On 12/03, Laurent Bercot wrote: > > /opt/local/bin/s6-svscan: error while loading shared libraries: > > libs6.so.2.9: cannot open shared object file: No such file or directory > > Is this because the '-rpath' linker option is not used at compile time > > to add the library directory to the runtime library search path? > > You could say that - or, more precisely, it's because your system isn't > configured to search for shared libraries in /opt/local/lib. It is on > purpose that s6 (or other skarnet.org software) does not automatically > add rpaths at build time: rpaths prevent run-time relocations, which can > be useful in a number of situations. Adding a rpath is hardcoding policy, > and by default, software should not hardcode policy. Interesting. Up until now, my understanding of best practice was that setting rpath was the right thing to do. But I see from your comments that this is not necessary true. Thank you for your explanation!
> There is no reason for you not to want to modify /etc/ld.so.conf. It's > the same thing as refusing to add /opt/local/bin to your PATH and then > complaining that the binaries are harder to find. Well, yeah, there are > conventional directories to host binaries and shared libraries, and the > convention exists for a reason; if you want to customize, you're free to > do so, but then you should use the adequate mechanism for customization, > which is adjusting your paths. Understood. Your rationale makes sense. I stand corrected. I tried adding /opt/local/lib to /etc/ld.so.conf, and then running ldconfig, and it does work. > (Note that a number of s6 executables *expect* to find other s6 > executables in their PATH. If /opt/local/bin is not in your default PATH, > and you have not used the --enable-absolute-paths configure option, > some s6 executables may not work correctly.) Yes, I was aware of that; thank you for noting it. > But there's another solution: as a software author, I shouldn't hardcode > policy, but as an admin, *you* absolutely can! So, if that is your > preference, you can add the rpath yourself at build time: > > env LDFLAGS=-Wl,-rpath,/opt/local/lib ./configure .... Indeed, that works as well! Thank you for the solution! Now, with no /opt/local/lib in /etc/ld.so.conf, ldd shows: ---- # ldd /opt/local/bin/s6-svscan linux-vdso.so.1 => (0x00007fffddfe2000) libs6.so.2.9 => /opt/local/lib/libs6.so.2.9 (0x00007fcac61dc000) libskarnet.so.2.9 => /opt/local/lib/libskarnet.so.2.9 (0x00007fcac5f9c000) libc.so.6 => /lib64/libc.so.6 (0x00007fcac5bce000) librt.so.1 => /lib64/librt.so.1 (0x00007fcac59c6000) /lib64/ld-linux-x86-64.so.2 (0x00007fcac63e9000) libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fcac57aa000) ---- So, problem solved in either of the two ways. Thanks! I still wonder about best practice, though. I'm curious about whether you have any more comments on this. Your rationale for using /etc/ld.so.conf makes sense to me. However, at http://xahlee.info/UnixResource_dir/_/ldpath.html David Barr says: Half-hearted attempts to improve things Some OS's (For example, Linux) have a configurable loader. You can configure what run-time paths to look in by modifying /etc/ld.so.conf. This is almost as bad as LD_LIBRARY_PATH! Install scripts should never modify this file! This file should contain only the standard library locations as shipped with the OS. Unfortunately, he does not explain *why* he thinks modifying /etc/ld.so.conf is almost as bad as LD_LIBRARY_PATH. I think I can imagine a problem arising around having multiple versions of the same library installed in parallel. If the executables and libraries do not use rpath and instead depend on /etc/ld.so.conf, then they can't declare exactly which library they want to use, and maybe you could end up with an executable using the wrong library or a bad mix of libraries? Obviously, they can declare to some extent using the major and minor shared object version. I'm not sure how this could go wrong. It seems that Fedora is not a fan of rpath in https://docs.fedoraproject.org/en-US/packaging-guidelines/#_beware_of_rpath where it says: Since the Linux dynamic linker is usually smarter than a hardcoded path, we usually do not permit the use of rpath in Fedora. But that's in the context of packaging for a distro, and in the "Rpath for Internal Libraries" section, it *does* allow for rpath usage for internal libraries. And Debian also seems not be a fan of rpath in https://wiki.debian.org/RpathIssue where it says: While there's no policy dictating the accepted use of RPATH, it's been a general consensus that RPATH use is discouraged, given the interactions between the above reasons and Debian's way of dealing with libraries and package dependencies. But again, it allows for using rpath for internal libraries: Currently, the only generally accepted use of this feature in Debian is to add non-standard library path (like /usr/lib/<package>) to libraries that are only intended to be used by the executables or other libraries within the same source package. Lastly, pkgsrc seems to use rpath based on https://www.netbsd.org/docs/pkgsrc/fixes.html#fixes.libtool which suggests using libtool with the '-rpath' option for linking. With pkgsrc, since it's a cross-platform packaging system, perhaps they don't want to depend on a feature like /etc/ld.so.conf since it is only available on a subset of the supported platforms. Kind regards, Lewis