I'm using xerces(http://xerces.apache.org) lib to parse a XML file in C++, so I downloaded the source code, ran a ./configure, make, make install, so when I execute
g++ -o parser parser.cpp
and I execute ./parser, I get:
./parser: error while loading shared libraries: libxerces-c-3.1.so: cannot open shared object file. No such file or directory.
When I search into /usr/lib or /lib I can't find where libxerces-c-3.1.so did go, nor where libxerces-c-3.1.so is. Does someone know how could I solve that problem?
Did you try running ldconfig command?
ldconfig examples
The only thing that I can think of is some issue with symbolic links, if it has crossed linking successfully.
Related question :https://stackoverflow.com/questions/480764/linux-error-while-loading-shared-libraries-cannot-open-shared-object-file-no-s
Related
I'm trying to build the SDL library from the source code. I've downloaded the compressed file (i.e. SDL2-2.0.3.tar.gz) and extracted it. I don't want to install the files in /usr/local. According to this link, I need to change the configure
The last command says "sudo" so we can write it to /usr/local (by
default). You can change this to a different location with the
--prefix option to the configure script. In fact, there are a LOT of good options you can use with configure! Be sure to check out its
--help option for details.
This is what I've done.
mkdir build
cd build
../configure
make
sudo make install
In install folder that I've created are the following files
share
lib
include
bin
Now I would like to run the test files. I've picked this testatomic.c and this is the command line
gcc testatomic.c -o test -I/home/xxxx/Desktop/SDL2-2.0.3/install/include/SDL2 -L/home/xxxx/Desktop/SDL2-2.0.3/install/lib -lSDL2 -lSDL2main
I get this error
error while loading shared libraries: libSDL2-2.0.so.0: cannot open shared object file: No such file or directory
In lib, these are the files
Where is the shared object file?
You're getting error when running resulting program because system's dynamic linker cannot find required library. Program requires libSDL2-2.0.so.0, linker looks for it in system-defined directories (/lib, /usr/lib, ..., - defined in /etc/ld.so.conf), but finds none - hence an error.
To inform linker where you want it to look for libraries, you can define LD_LIBRARY_PATH environment variable, e.g. in your case:
export LD_LIBRARY_PATH="$HOME/Desktop/SDL2-2.0.3/install/lib"
./test
Other ways is installing libraries in standard location, defining LD_LIBRARY_PATH in your .bashrc (or whatever shell you use), or using rpath, e.g. adding -Wl,-rpath=$HOME/Desktop/SDL2-2.0.3/install/lib at the end of your compilation line.
I was able to fix this problem with:
sudo apt install libsdl2-dev
I too had:
./01_hello_SDL: error while loading shared libraries: libSDL2-2.0.so.0: cannot open shared object file: No such file or directory
as a result of compiling the first C++ program (using the SDL headers) as part of the Lazy Foo tutorial. I found out that libSDL2-2.0.so.0 was just using the find command in the GUI. It turned out to be in /usr/local/lib
Then in terminal I typed:
export LD_LIBRARY_PATH="/usr/local/lib"
I checked the value of LD_LIBRARY_PATH using:
echo $LD_LIBRARY_PATH
I recompiled (don't know if that was necessary) and voila, it worked.
I use gsl.
After I compiled my .cpp file and run it, I faced with below error:
error while loading shared libraries: libgsl.so.0: cannot open shared object file: No such file or directory
I found same as this problem in:
https://groups.google.com/forum/#!topic/cortex_var/6vluX7pP0Sk
&
Linux error while loading shared libraries: cannot open shared object file: No such file or directory
&
http://www.gnu.org/software/gsl/manual/html_node/Shared-Libraries.html
And I have done as in the above links wrote but the error is still remained.
Can anyone help me?
To make it work do the following steps
Start Borne Shell
$LD_LIBRARY_PATH= path to your gsl lib folder inside the gsl installation folder
$export LD_LIBRARY_PATH
now run your executable
It should work fine.
First, you need to locate the file (libgsl.so.0). You can do this, for example, by using the find command:
sudo find / -name "libgsl.so.0"
Let us assume, the file is located in /usr/local/lib.
(If the file has not been found, install the corresponding package or download the source, build it and install it.)
Now, you have two options:
(1) Quick & Dirty:
LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/lib
export LD_LIBRARY_PATH
This adds the path of the library to an environment variable. The disadvantage of this option is, that it is only valid for the current session. It will not work for other users. It will not work once you log off and on again.
(2) Permanent:
Review your /etc/ld.so.conf. If /usr/local/lib is not listed there, add it. Now, run ldconfig to detect the shared object file and add it to some system-wide index.
I got the same error with Krita on Arch Linux. I made a symlink with
ln /usr/lib/libgsl.so /usr/lib/libgsl.so.0
and that fixed it.
In my experience, fastStructure depends on gsl 1.6 but not the latest version.
wget http://gnu.mirror.vexxhost.com/gsl/gsl-1.6.tar.gz
tar -zxvf gsl-1.6.tar.gz
cd gsl-1.16
./configure
make
sudo make install
Add these lines to your .bashrc file on your home directory.
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/lib
export CFLAGS="-I/usr/local/include"
export LDFLAGS="-L/usr/local/lib"
then, run source ~/.bashrc to set these environment variables.
It works fine when I change the version from the latest to the 1.6.
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/home/shg047/software/gsl/lib/
such as: to-mr: error while loading shared libraries: libgsl.so.19: cannot open shared object file: No such file or directory
Have you tried updating your library? The program I was trying to run simply needed a newer version of gsl (I had 1.9.5 while it needed 2.0.0 or newer).
If you are on arch you can run:
yaourt gsl
and select the appropriate one.
You can use gsl-config --libs in you makefile or in the command line when you link the gsl library. Just type gsl-config you can find the options it offers to you. Choose the options you need, you will find compile and link process much easier than before. As a result, when I type gsl-config --libs in my terminal, I get -L/usr/local/lib -lgsl -lgslcblas -lm. Although it is very simple, first you should know where you gsl is installed. You can add the directory to the PATH environment variable or use the absolute path to execute gsl-config .
I needed libgsl.so.19:
/snap/inkscape/current/bin/inkscape: error while loading shared libraries: libgsl.so.19: cannot open shared object file: No such file or directory
I solved it with:
Installing Anaconda
searched for libgsl.so.19 and found it in ~/anaconda3/lib
run LD_LIBRARY_PATH=$LD_LIBRARY_PATH:~/anaconda3/lib (best add it to ~/.basrc)
I'm trying to compile my program and it returns this error :
usr/bin/ld: cannot find -l<nameOfTheLibrary>
in my makefile I use the command g++ and link to my library which is a symbolic link to my library located on an other directory.
Is there an option to add to make it work please?
To figure out what the linker is looking for, run it in verbose mode.
For example, I encountered this issue while trying to compile MySQL with ZLIB support. I was receiving an error like this during compilation:
/usr/bin/ld: cannot find -lzlib
I did some Googl'ing and kept coming across different issues of the same kind where people would say to make sure the .so file actually exists and if it doesn't, then create a symlink to the versioned file, for example, zlib.so.1.2.8. But, when I checked, zlib.so DID exist. So, I thought, surely that couldn't be the problem.
I came across another post on the Internets that suggested to run make with LD_DEBUG=all:
LD_DEBUG=all make
Although I got a TON of debugging output, it wasn't actually helpful. It added more confusion than anything else. So, I was about to give up.
Then, I had an epiphany. I thought to actually check the help text for the ld command:
ld --help
From that, I figured out how to run ld in verbose mode (imagine that):
ld -lzlib --verbose
This is the output I got:
==================================================
attempt to open /usr/x86_64-linux-gnu/lib64/libzlib.so failed
attempt to open /usr/x86_64-linux-gnu/lib64/libzlib.a failed
attempt to open /usr/local/lib64/libzlib.so failed
attempt to open /usr/local/lib64/libzlib.a failed
attempt to open /lib64/libzlib.so failed
attempt to open /lib64/libzlib.a failed
attempt to open /usr/lib64/libzlib.so failed
attempt to open /usr/lib64/libzlib.a failed
attempt to open /usr/x86_64-linux-gnu/lib/libzlib.so failed
attempt to open /usr/x86_64-linux-gnu/lib/libzlib.a failed
attempt to open /usr/local/lib/libzlib.so failed
attempt to open /usr/local/lib/libzlib.a failed
attempt to open /lib/libzlib.so failed
attempt to open /lib/libzlib.a failed
attempt to open /usr/lib/libzlib.so failed
attempt to open /usr/lib/libzlib.a failed
/usr/bin/ld.bfd.real: cannot find -lzlib
Ding, ding, ding...
So, to finally fix it so I could compile MySQL with my own version of ZLIB (rather than the bundled version):
sudo ln -s /usr/lib/libz.so.1.2.8 /usr/lib/libzlib.so
Voila!
If your library name is say libxyz.so and it is located on path say:
/home/user/myDir
then to link it to your program:
g++ -L/home/user/myDir -lxyz myprog.cpp -o myprog
There does not seem to be any answer which addresses the very common beginner problem of failing to install the required library in the first place.
On Debianish platforms, if libfoo is missing, you can frequently install it with something like
apt-get install libfoo-dev
The -dev version of the package is required for development work, even trivial development work such as compiling source code to link to the library.
The package name will sometimes require some decorations (libfoo0-dev? foo-dev without the lib prefix? etc), or you can simply use your distro's package search to find out precisely which packages provide a particular file.
(If there is more than one, you will need to find out what their differences are. Picking the coolest or the most popular is a common shortcut, but not an acceptable procedure for any serious development work.)
For other architectures (most notably RPM) similar procedures apply, though the details will be different.
Compile Time
When g++ says cannot find -l<nameOfTheLibrary>, it means that g++ looked for the file lib{nameOfTheLibrary}.so, but it couldn't find it in the shared library search path, which by default points to /usr/lib and /usr/local/lib and somewhere else maybe.
To resolve this problem, you should either provide the library file (lib{nameOfTheLibrary}.so) in those search paths or use -L command option. -L{path} tells the g++ (actually ld) to find library files in path {path} in addition to default paths.
Example: Assuming you have a library at /home/taylor/libswift.so, and you want to link your app to this library. In this case you should supply the g++ with the following options:
g++ main.cpp -o main -L/home/taylor -lswift
Note 1: -l option gets the library name without lib and .so at its beginning and end.
Note 2: In some cases, the library file name is followed by its version, for instance libswift.so.1.2. In these cases, g++ also cannot find the library file. A simple workaround to fix this is creating a symbolic link to libswift.so.1.2 called libswift.so.
Runtime
When you link your app to a shared library, it's required that library stays available whenever you run the app. In runtime your app (actually dynamic linker) looks for its libraries in LD_LIBRARY_PATH. It's an environment variable which stores a list of paths.
Example: In case of our libswift.so example, dynamic linker cannot find libswift.so in LD_LIBRARY_PATH (which points to default search paths). To fix the problem you should append that variable with the path libswift.so is in.
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/home/taylor
During compilation with g++ via make define LIBRARY_PATH if it may not be appropriate to change the Makefile with the -Loption. I had put my extra library in /opt/lib so I did:
$ export LIBRARY_PATH=/opt/lib/
and then ran make for successful compilation and linking.
To run the program with a shared library define:
$ export LD_LIBRARY_PATH=/opt/lib/
before executing the program.
First, you need to know the naming rule of lxxx:
/usr/bin/ld: cannot find -lc
/usr/bin/ld: cannot find -lltdl
/usr/bin/ld: cannot find -lXtst
lc means libc.so, lltdl means libltdl.so, lXtst means libXts.so.
So, it is lib + lib-name + .so
Once we know the name, we can use locate to find the path of this lxxx.so file.
$ locate libiconv.so
/home/user/anaconda3/lib/libiconv.so # <-- right here
/home/user/anaconda3/lib/libiconv.so.2
/home/user/anaconda3/lib/libiconv.so.2.5.1
/home/user/anaconda3/lib/preloadable_libiconv.so
/home/user/anaconda3/pkgs/libiconv-1.14-0/lib/libiconv.so
/home/user/anaconda3/pkgs/libiconv-1.14-0/lib/libiconv.so.2
/home/user/anaconda3/pkgs/libiconv-1.14-0/lib/libiconv.so.2.5.1
/home/user/anaconda3/pkgs/libiconv-1.14-0/lib/preloadable_libiconv.so
If you cannot find it, you need to install it by yum (I use CentOS). Usually you have this file, but it does not link to right place.
Link it to the right place, usually it is /lib64 or /usr/lib64
$ sudo ln -s /home/user/anaconda3/lib/libiconv.so /usr/lib64/
Done!
ref: https://i-pogo.blogspot.jp/2010/01/usrbinld-cannot-find-lxxx.html
When you compile your program you must supply the path to the library; in g++ use the -L option:
g++ myprogram.cc -o myprogram -lmylib -L/path/foo/bar
I had this problem with compiling LXC on a fresh VM with Centos 7.8. I tried all the above and failed. Some suggested removing the -static flag from the compiler configuration but I didn't want to change anything.
The only thing that helped was to install glibc-static and retry. Hope that helps someone.
Check the location of your library, for example lxxx.so:
locate lxxx.so
If it is not in the /usr/lib folder, type this:
sudo cp yourpath/lxxx.so /usr/lib
Done.
Apart from the answers already given, it may also be the case that the *.so file exists but is not named properly. Or it may be the case that *.so file exists but it is owned by another user / root.
Issue 1: Improper name
If you are linking the file as -l<nameOfLibrary>
then library file name MUST be of the form lib<nameOfLibrary>
If you only have <nameOfLibrary>.so file, rename it!
Issue 2: Wrong owner
To verify that this is not the problem - do
ls -l /path/to/.so/file
If the file is owned by root or another user, you need to do
sudo chown yourUserName:yourUserName /path/to/.so/file
Here is Ubuntu information of my laptop.
lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 18.04.2 LTS
Release: 18.04
Codename: bionic
I use locate to find the .so files for boost_filesystem and boost_system
locate libboost_filesystem
locate libboost_system
Then link .so files to /usr/lib and rename to .so
sudo ln -s /usr/lib/x86_64-linux-gnu/libboost_filesystem.so.1.65.1 /usr/lib/libboost_filesystem.so
sudo ln -s /usr/lib/x86_64-linux-gnu/libboost_system.so.1.65.1 /usr/lib/libboost_system.so
Done! R package velocyto.R was successfully installed!
This error may also be brought about if the symbolic link is to a dynamic library, .so, but for legacy reasons -static appears among the link flags. If so, try removing it.
The library I was trying to link to turned out to have a non-standard name (i.e. wasn't prefixed with 'lib'), so they recommended using a command like this to compile it -
gcc test.c -Iinclude lib/cspice.a -lm
I encountered the same error message.
I built the cmocka as a so and tried to link it to my executable.
But ld always complains below:
/usr/bin/ld: cannot find -lcmocka
It turns out that there are 3 files generated after cmocka is built:
libcmocka.so
libcmocka.so.0
libcmocka.so.0.7.0
1 and 2 are symbol links and only 3 is the real file.
I only copied the 1 to my library folder, where ld failed to find the 3.
After I copied all 3, ld works.
I have a project organized as
\bin\cmain
\lib\libxmlrpc_client++.a
\lib\libxmlrpc_client++.so.4
\lib\libxmlrpc_client++.so.4.16
My c program cmain need to dynamically link clib.so.4. While I compile the code, I use -L.../lib to indicate directory lib and use -lxmlrpc_client++. However, my code get error while loading shared libraries:
libxmlrpc_client++.so.4: cannot open shared object file: No such file or directory
Any ideas to fix this?
PS: Problem solved, a good reference to the problem: http://gcc.gnu.org/ml/gcc-help/2005-12/msg00017.html
You need to tell the dynamic linker where to look for the libraries. Assuming this is some sort of UNIX/Linux system, this can be done either via setting the LD_LIBRARY_PATH environment variable before executing the program:
export LD_LIBRARY_PATH=/path/to/lib
./run-my-program
or by setting the run-time linker path during compile time:
gcc -L/path/to/lib -Wl,-rpath,/path/to/lib -lxmlrpc_client++ ...
./run-my-program
Both approaches have problems. Google for "why LD_LIBRARY_PATH is bad". The command-line options for setting the run-time linker path varies from one compiler to another.
You should use -Llib instead of -L..
Is that softlink broken? ls -l, make sure your pointing to the correct file.
Example Error :
[root#localhost ~]# ./conn 127.0.0.1 6379 opencc ./conn: error while
loading shared libraries: libhiredis.so.1.0.3-dev: cannot open shared
object file: No such file or directory
Solution
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
I have compiled this library successfully. It generates a libcds2.la file that I am trying to link into my own project. I have all files (including the .h file) in the same directory as my project file. When I try to link and use the functions of said library, using:
g++ -o test -I/opt/include/ -L/opt/lib/ -lcds2 libcdsNoptrs.cpp util.cpp
comes back with
./test: error while loading shared libraries: libcds2.so.2:
cannot open shared object file: No such file or directory
whatever that is. But the point is that most of the time it just doesn't recognize the library. I assume I'm doing something wrong with the file paths, but can't figure it out. My test file is a C++ file including #include "libcds2/array.h" and everything is installed in opt/lib, opt/include, ugly, I know, but that's what the Makefile generated.
Any pointers?
The libtool .la is a 'meta data' file. After building the cds2 library, it's expected that libtool will also be used in 'link' mode to build any of the package's tests, etc.
Typically, the in the directory you find the .la file, you will find the .a and .so under the .libs subdirectory. The .libs/libcds2.a file will be found there, provided configure was given the --enable-static option (or it is enabled by default). But, my understanding is that you've installed the package in /opt :
g++ -I/opt/include/ libcdsNoptrs.cpp util.cpp -o test /opt/lib/libcds2.a
Otherwise, if libcds2 isn't installed, just supply a path to: .../libcds2/lib/.libs/libcds2.a
Unless you want to use libtool in --link mode with -static to handle everything. But learning the advantages of libtool is usually an exercise for a rainy day:)