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.
Error while loading shared libraries, cannot open shared object file: No such file or directory (hiredis)
The problem was the libhiredis wasn't in the ldconfig path. While the build process was correct and it copied everything to the correct directory ldconfig did not know about its location.
You can use ldconfig -p
to see all library ldconfig currently know about.
You can add the path to ldconfig with
sudo echo "/usr/local/lib" > /etc/ld.so.conf.d/local.conf
&
sudo ldconfig
cannot open shared object file: No such file or directory | including libbpf with userspace program
You should add the libbpf library directory to your LD_LIBRARY_PATH
variable.
$ LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/build/root/usr/lib64
$ export LD_LIBRARY_PATH
Then go ahead an run the program. Note that if you run it with sudo, you may also need to set root's LD_LIBRARY_PATH
$ sudo su
# LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/build/root/usr/lib64
# export LD_LIBRARY_PATH
# ./user
You can verify that libbfp was found with the same ldd command.
Error loading shared libraries: cannot open shared object file :: on external hardware
The system normally searches for shared objects in a fixed set of directories. You can handle around this by defining the environment variable LD_LIBRARY_PATH
and adding the directory where you install the shared libraries into.
Or you can add those libraries to some of the standard libraries directories and execute ldconfig -a
to update the cache of shared libraries.
See ldconfig(8)
, for more info.
edit
There are two mechanisms to load a shared object.
The first is the normal library loading mechanism, that specifies what has to be loaded at start executable time, and implies linking your executable with the shared objects. This is what you do in your
Makefile
. You specify the shared executables, and theld.so.xxx
shared object (which is linked to your application when you are dynamically linking it) loads and follows all the unresolved identifiers to find a place for them in the virtual address space. Theld.so.xxx
object uses the/etc/ld.so.cache
file, that is just a hash table with the directories and shared executables available to be loaded this way. That file is indexed by what is called thesoname
(which is something useful to allow different versions of the same library to coexist in the same system) and normally maps to the last versioned shared found in the list of directories listed in the file/etc/ld.so.conf
(this is static information to accelerate the process of loading libraries and is generated at each boot of the system). If the shared was found at link time (this mechanism is not used byld
, but only to load the libraries at program start time) to have asoname
, then thatsoname
is searched in the/etc/ld.so.cache
to find the final file that has to be loaded. This cache is built on each boot of the system, so you don't have to cope with that, but only if you don't want to reboot and you install a new library for system use. It is important to note that shared objects must be givensoname
s for this to work, and that the list of directories in the file/etc/ld.so.conf
are the only directories used to search for files. This means that for a standard library to be usable, you need to put it in one of this directories (or add the directory to the list in/etc/ld.so.conf
) and then executeldconfig -a
to rebuild the cache and let it include a reference for the file under thatsoname
.The other way it to add to the list of search places a list in the form of a PATH variable. The variable is
LD_LIBRARY_PATH
so, in case you have your shared objects in${HOME}/libs
, you can add this line to your.profile
:export LD_LIBRARY_PATH=${HOME}/libs
or
setenv LD_LIBRARY_PATH ${HOME}/libs
this allows your library to live outside of the standard directories, but think twice, as this is a far less efficient way to load a file (as it involves processing a list of directories to look for the final shared objects, while the previous approach is direct, you ask for the file matching the
soname
thatld.so.xxx
asks for, only one search, only one step)The second is to use a library function
dlopen(3)
that allow you to load a shared object and do some housekeeping before calling anything inside. The dl library allows you to search for a symbol in the shared executable and then decide if you interpret it as data or a jump target.dlopen()
just opens and loads into the virtual address space a shared object. It resolves the dependencies (if requested to) and is the more flexible way (but it is also nontransparent) to load unknown code for execution. This is the way plugins normally work. You decide in a config file, or dynamically what to load, and then you load it. The program doesn't have to know previously the symbol table of what you are dealing with and you are free to implement whatever you want in the module you are loading.
All of these methods work with ELF binaries, so you have a lot of freedom, but also a lot of complexity on it.
more...
As i've seen from your compilation:
- you are including
-l
in the compile only commands, the libraries are only needed if you are linking an executable, don't put libraries in the compile phase. for a library to be searched and selected by the linker, it has to be named as
lib<name>.so
(without the version info at the end) so this means that you normally find three names for a standard library (let me use the math library-lm
as an example):/usr/lib/libm.so.3.2.8 # this is the ELF file with the library contents.
/usr/lib/libm.so.3 -> libm.so.3.2.8 # this is the soname used to create the library.
/usr/lib/libm.so -> libm.so.3 # this is the actual file the ld(1) program searches for when using -lm.
those links have to be created, as the system normally doesn't. This is part of the installation procedure for a shared library. The soname
link allows you to have different versions of a library and detect which one of them will be used at runtime (all must be compatible so you can interchange, when you make an incompatible modification, then you have to change the soname, so the system doesn't get confused on loading)
It is very important to know that the ld(1)
program only selects a library if it is called lib<name>.so
, with no version info. Indeed, the compiler first searchs for lib<name>.so
, then for lib<name>.a
, then it complains.
It is very important to put -L
places to search for libraries before any -l
option that will use those directories in the linking parameters.
You only need to run ldconfig -a
and install the library in a system directory if you are not going to use the LD_LIBRARY_PATH
mechanism. (this mechanism doesn't work for root account, for obvious reasons :))
Expecting this added comments give some light to the process.
Related Topics
Awk or Sed to Remove All Text After X Occurence in Each Line of File
How to Get Cron to Call in the Correct Paths
How to Generate a Core Dump in Linux on a Segmentation Fault
How to Invoke a System Call Via Syscall or Sysenter in Inline Assembly
What Is the Runtime Performance Cost of a Docker Container
How to Run a Shell Script When a File or Directory Changes
Bash Function to Find Newest File Matching Pattern
How to Determine If a Process Runs Inside Lxc/Docker
Linux and I/O Completion Ports
How to Reload Google Chrome Tab from Terminal
How to Use Sudo to Redirect Output to a Location I Don't Have Permission to Write To
How to Kill a Child Process After a Given Timeout in Bash
What Does the Number in Parentheses Shown After Unix Command Names in Manpages Mean
How to Replace Spaces in File Names Using a Bash Script
Bluetooth Low Energy: Listening For Notifications/Indications in Linux