I encountered this problem when I compiled mosquitto on my Fedora 21 box from source.
mosquitto_pub: error while loading shared libraries:
libmosquitto.so.1: cannot open shared object file: No such file or
directory
The clients (i.e mosquitto_pub and mosquitto_sub) keep throwing that error even with reinstallation.
Assuming you have installed the libraries to /usr/local/lib, which is the default, the correct answer is to run /sbin/ldconfig as root/sudo.
On some systems you will need to add /usr/local/lib to the paths that ld caches, e.g.
echo /usr/local/lib > /etc/ld.so.conf.d/local.conf
I fixed this problem with sysmlinks
$vi /etc/ld.so.conf
include ld.so.conf.d/*.conf
include /usr/local/lib
/usr/lib
/usr/local/lib
$/sbin/ldconfig
$ln -s /usr/local/lib/libmosquitto.so.1 /usr/lib/libmosquitto.so.1
This indicates that the linker does not know where to find the library. Just run sudo /sbin/ldconfig to update the linker cache of libraries. This is not something that is unique to mosquitto.
I installed mosquitto from source on Ubuntu 20.04. So, the libmosquitto.so.1 was in the same directory as the source files. I copied it to usr/lib/x86_64-linux-gnufolder. Then running the mosquitto_sub worked!
Related
I tried to execute spike this way by navigating to the folder the executable is in:
cd ~/riscv-tools/riscv-isa-sim/build
./spike
I get this error message:
./spike: error while loading shared libraries: libriscv.so: cannot open shared object file: No such file or directory
It is significant that the file it claims to not find is in the same directory as the spike executable (in the build directory) - any help?
The dynamic linker generally looks for shared libraries in predefined system directories such as /lib, /usr/lib as specified by ldconfig.
You can tell the linker to search in other directories with LD_LIBRARY_PATH:
LD_LIBRARY_PATH=. ./spike
The usual way is to execute Spike it to execute it from the installed location, e.g. install it like this:
cd riscv-isa-sim
mkdir build
cd build
../configure --prefix=$HOME/local/riscv/spike
make
make install
And then execute it:
~/local/riscv/spike/bin/spike ...
No need to mess around with your LD_LIBRARY_PATH then (which really should be avoided, if possible).
Although I can see that libhdf5.so.100 is actually inside /usr/local/lib, I receive the following error when running octave:
bash-4.3$ octave
/usr/local/bin/octave-cli-4.0.2: error while loading shared libraries: libhdf5.so.100: cannot open shared object file: No such file or directory
I built octave 4.0.2 myself.
I added the line /usr/local/lib to /etc/ld.so.conf and then ran sudo ldconfig. Problem solved.
I'm using a node module png which use libpng. After installing libpng, I find some libs in /usr/local/lib. I require the png module:
var png = require('png')
It complained that libpng16.so could not be found.
Error: libpng16.so.16: cannot open shared object file: No such file or directory
But libpng16.so.16 does exist in /usr/local/lib. Then I copy all libpng* to /usr/lib and run code above again, no error for this time!
My question: how could I let Node search libs in /usr/local/lib?
Thanks!
This is a Linux "installing libraries" issue, not a node.js issue (I was confused by the same thing & landed here looking for ideas).
make install will typically copy the library to /usr/local/lib and output some boilerplate suggesting that you modify LD_LIBRARY_PATH or update the ld config. But it doesn't do this for you.
(One thing that can make this more confusing is that the compiler toolchain will search /usr/local by default, so any dependent libraries will compile/link fine.)
Running ldconfig (/sbin/ldconfig) as root or with sudo will update the run-time linker cache, and fix the problem. If not, check that at least one of /etc/ld.so.conf or any of the files in /etc/ld.so.conf.d/ contains the line '/usr/local/lib'.
For more information, run man ldconfig
I'm trying run a program(Snort) that uses libdnet but it fails to find it and outputs:
snort: error while loading shared libraries: libdnet.1: cannot open
shared object file: No such file or directory
Now I know that I should add the library by running ldconfig and putting path to the library in /etc/ld.so.conf. libdnet is located in /usr/local/lib so I don't have to modify ld.so.conf since it already covers that dirctory. So I ran the following commands and tracing the output, I noticed my library is not being loaded.
ldconfig -v
Apparently ldconfig only loads files that have .so somewhere in their names and libdnet.1 doesn't match the pattern.
I've built libdnet from source and installed it using ./configure; make; make install commands. I'd rather not install it using the package manager unless I have to. What should I do?
EDIT:
It says here that libraries should match the patter lib*.so* but I can't rename the library. I neither made it nor am I using it in my own app: if I rename it it will be loaded but I think Snort is looking for libdnet.1 not libdnet.so.1.
Found the answer here. The Solution was simple: make a copy that matches the pattern.
cp /usr/local/lib/libdnet.1.0.1 /usr/local/lib/libdnet.so.1.0.1
A less preferred alternative:
$ LD_LIBRARY_PATH=/usr/local/lib
$ export LD_LIBRARY_PATH
I'm venturing into the world of C++ and Linux, and am having problems linking against a shared library.
I have a library, libicuuc.so.44.1, installed in /usr/local/lib. There is also a link in the same directory, libicuuc.so.44 pointing to that library.
My /etc/ld.so.conf reads:
include /etc/ld.so.conf.d/*.conf
I have a file, /etc/ld.so.conf.d/libc.conf, that contains:
# libc default configuration
/usr/local/lib
However, when I compile my program (that includes LIBS += -licuuc), I get the following error at runtime:
error while loading shared libraries:
libicuuc.so.44: cannot open shared
object file: No such file or directory
I am using Qt Creator on Ubuntu 10.04.
Any help is greatly appreciated!
Did you modify by yourself /etc/ld.so.conf.d/libc.conf ?
If yes, then run (as root) ldconfig to re-read the config.