Re: s6-svscan can't find shared libraries

From: J. Lewis Muir <jlmuir_at_imca-cat.org>
Date: Tue, 3 Dec 2019 23:30:28 -0600

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

Received on Wed Dec 04 2019 - 05:30:28 UTC