Linux Service Can't Load Library Path in The /Etc/Ld.So.Conf.D

Linux service can't load library path in the /etc/ld.so.conf.d

Did you run ldconfig (as root) lately? There's a shared library cache that's updated by that program, and if you updated a file in /etc/ld.so.conf.d without running ldconfig, the cache data could be out of date.

library not found although I use ldconfig and /etc/ld.so.conf.d/lib.conf

I've found a workaround provided by Tom in the Read Hat Bugzilla bug-tracking system at https://bugzilla.redhat.com/show_bug.cgi?id=1404662.

Yeah, so it looks like while R is perfectly happy using libRblas.so as a > symlink to libopenblas.so.0, externally, nothing else is.
The speedup from using openblas is significant, so the fix is to build a copy of openblas that has the libRblas.so filename and soname, and use that instead of the symlink. I have a new build of openblas going which adds this, then I'll do a new round of R builds that depend on it.

As a temporary workaround, you can run (as root):
rm -f /usr/lib64/R/lib/libRblas.so
mv /usr/lib64/R/lib/libRrefblas.so /usr/lib64/R/lib/libRblas.so

That will restore the unoptimized libRblas.so that R provides.

Oh, and run /sbin/ldconfig (as root) after moving libRrefblas.so so that the ldcache is updated.

ld.so.conf does not get loaded by ldconfig

You have to add library or directory itself:

/full/Path/to/library.so/or/directory to /etc/ld.so.conf file

You must remove include word before directory in your config file.

From man ldconfig:

The ldconfig utility is used to prepare a set of ``hints'' for use
by the
dynamic linker to facilitate quick lookup of shared libraries available
in multiple directories.

<...>

Files named on the command line are expected to contain directories to
scan for shared libraries. Each directory's pathname must start on a new
line. Blank lines and lines starting with the comment character `#' are
ignored. Filenames must conform to the lib*.so.[0-9] pattern in order to
be added to the hints file.

Linux error while loading shared libraries: cannot open shared object file: No such file or directory

Update

While what I write below is true as a general answer about shared libraries, I think the most frequent cause of these sorts of message is because you've installed a package, but not installed the -dev version of that package.

---

Well, it's not lying - there is no libpthread_rt.so.1 in that listing. You probably need to re-configure and re-build it so that it depends on the library you have, or install whatever provides libpthread_rt.so.1.

Generally, the numbers after the .so are version numbers, and you'll often find that they are symlinks to each other, so if you have version 1.1 of libfoo.so, you'll have a real file libfoo.so.1.0, and symlinks foo.so and foo.so.1 pointing to the libfoo.so.1.0. And if you install version 1.1 without removing the other one, you'll have a libfoo.so.1.1, and libfoo.so.1 and libfoo.so will now point to the new one, but any code that requires that exact version can use the libfoo.so.1.0 file. Code that just relies on the version 1 API, but doesn't care if it's 1.0 or 1.1 will specify libfoo.so.1. As orip pointed out in the comments, this is explained well at here.

In your case, you might get away with symlinking libpthread_rt.so.1 to libpthread_rt.so. No guarantees that it won't break your code and eat your TV dinners, though.

Why can't ld find library from path in /etc/ld.so.conf?

ld is the static linker. ld.so is the dynamic linker (and ldconfig & ldd are related to the dynamic linker).

You need to add -L/opt/vertica/lib64/ to your ld arguments at link time (and you usually should link with gcc or g++). Practically speaking, this means editing your build infrastructure -e.g. your Makefile - to add a few dozen characters.

See ld.so(8), ldd(1), ld(1), ldconfig(8)

Read also Drepper's paper: How To Write Shared Libraries, Program Library HowTo & Levine's book: Linkers and Loaders

Can't link dynamic library when running C language with root privileges?

The linker flag -L just tells the linker where to look for the library (or a library stub, if such is used) at link time. It does not influence the library search path at runtime.

For a system wide installed library you'd place the library in a place that's been configured in the global linker search path, set through /etc/ld.so.conf and files in /etc/ld.so.conf.d.

However it is perfectly possible to specify additional search paths specific to certain binaries by means of the so callled rpath. The rpath is set using the (you guessed it) rpath extra linker flag -Wl,-rpath.

Linking the program with

gcc -o … -Wl,-rpath='${ORIGIN}' …

would make the ELF interpreter (the piece of code that loads ELF binaries and does dynamic linkage) to also look for additional libraries right next to the program binary. You can read up on the details of rpaths in the ld.so manpage.

Be aware that rpaths invoke certain security considerations.

Cannot load libraries when Qt application is launched from systemd

Most probably the linker directories are not known in the context of systemctl. Try setting the environment variable LD_LIBRARY_PATH to the relevant dirs at the start of your service script; see man ld.so for details. Or look at other service scripts on your system to get an idea how the environment is correctly set there.

---

Related Topics