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.
Related
I use CentOS 7 and would like to use some Anaconda python package that requires GLIBC_2.18 while the host OS only provides 2.17. I tried compiling a newer version of glibc myself following these instructions. When I try to run any executable with this newer glibc I am getting an error:
$ ./testrun.sh ls
ls: error while loading shared libraries: ls: cannot open shared object file: No such file or director
Is there a workaround for this issue?
Update 1:
As per suggestion in this answer I needed to specify the full path to the executable, which now gives a different error message:
$ cd glibc-2.20/build # build directory
$ ./testrun.sh /bin/ls
/bin/ls: error while loading shared libraries: libselinux.so.1: cannot open shared object file: No such file or directory
Update 2:
Adding paths to the system libraries in testrun.sh solved the problem. I can not only run ls but also the aforementioned python package. Thank you!
Try ./testrun.sh /bin/ls.
That said, you will really be better off building the Python package for your system, instead of trying to make non-system GLIBC, as Danila Vershinin suggested.
Update:
libselinux.so.1: ...: No such file or directory
The testrun.sh for the new GLIBC does not look in system directories (e.g. /usr/lib64). You need to append system directories to the --library-path it uses. E.g. change
--library-path "${builddir}":"${builddir}"/math:"${builddir}"/elf:"${builddir}"/dlfcn:"${builddir}"/nss:"${builddir}"/nis:"${builddir}"/rt:"${builddir}"/resolv:"${builddir}"/mathvec:"${builddir}"/support:"${builddir}"/crypt:"${builddir}"/nptl
to:
--library-path "${builddir}":"${builddir}"/math:"${builddir}"/elf:"${builddir}"/dlfcn:"${builddir}"/nss:"${builddir}"/nis:"${builddir}"/rt:"${builddir}"/resolv:"${builddir}"/mathvec:"${builddir}"/support:"${builddir}"/crypt:"${builddir}"/nptl:/usr/lib64:/lib64
(or something like that).
I am running go build and encounter following issue:
/tmp/___go_build_myproject_: error while loading shared libraries: libSomeLib_x64.so: cannot open shared object file: No such file or directory
I have libSomeLib_x64.so compiled in another directory.
From this question I know that I should use ldconfig to link lib.
I tried both add lib path to /etc/ld.so.conf and to export LD_LIBRARY_PATH but nothing helped. How can I get rid of the error?
Answer is here: https://codeyarns.com/2017/11/02/how-shared-library-locations-are-found-at-runtime/
I added my *.so libs into /lib/ directory.
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).
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!
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