Program is part of the Xenomai test suite, cross-compiled from Linux PC into Linux+Xenomai ARM toolchain.
# echo $LD_LIBRARY_PATH
/lib
# ls /lib
ld-2.3.3.so libdl-2.3.3.so libpthread-0.10.so
ld-linux.so.2 libdl.so.2 libpthread.so.0
libc-2.3.3.so libgcc_s.so libpthread_rt.so
libc.so.6 libgcc_s.so.1 libstdc++.so.6
libcrypt-2.3.3.so libm-2.3.3.so libstdc++.so.6.0.9
libcrypt.so.1 libm.so.6
# ./clocktest
./clocktest: error while loading shared libraries: libpthread_rt.so.1: cannot open shared object file: No such file or directory
Is the .1 at the end part of the filename? What does that mean anyway?
Your library is a dynamic library.
You need to tell the operating system where it can locate it at runtime.
To do so,
we will need to do those easy steps:
Find where the library is placed if you don't know it.
sudo find / -name the_name_of_the_file.so
Check for the existence of the dynamic library path environment variable(LD_LIBRARY_PATH)
echo $LD_LIBRARY_PATH
If there is nothing to be displayed, add a default path value (or not if you wish to)
LD_LIBRARY_PATH=/usr/local/lib
We add the desired path, export it and try the application.
Note that the path should be the directory where the path.so.something is. So if path.so.something is in /my_library/path.so.something, it should be:
LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/my_library/
export LD_LIBRARY_PATH
./my_app
Reference to source
Here are a few solutions you can try:
ldconfig
As AbiusX pointed out: If you have just now installed the library, you may simply need to run ldconfig.
sudo ldconfig
ldconfig creates the necessary links and cache to the most recent
shared libraries found in the directories specified on the command
line, in the file /etc/ld.so.conf, and in the trusted directories
(/lib and /usr/lib).
Usually your package manager will take care of this when you install a new library, but not always, and it won't hurt to run ldconfig even if that is not your issue.
Dev package or wrong version
If that doesn't work, I would also check out Paul's suggestion and look for a "-dev" version of the library. Many libraries are split into dev and non-dev packages. You can use this command to look for it:
apt-cache search <libraryname>
This can also help if you simply have the wrong version of the library installed. Some libraries are published in different versions simultaneously, for example, Python.
Library location
If you are sure that the right package is installed, and ldconfig didn't find it, it may just be in a nonstandard directory. By default, ldconfig looks in /lib, /usr/lib, and directories listed in /etc/ld.so.conf and $LD_LIBRARY_PATH. If your library is somewhere else, you can either add the directory on its own line in /etc/ld.so.conf, append the library's path to $LD_LIBRARY_PATH, or move the library into /usr/lib. Then run ldconfig.
To find out where the library is, try this:
sudo find / -iname *libraryname*.so*
(Replace libraryname with the name of your library)
If you go the $LD_LIBRARY_PATH route, you'll want to put that into your ~/.bashrc file so it will run every time you log in:
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/path/to/library
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.
You need to ensure that you specify the library path during
linking when you compile your .c file:
gcc -I/usr/local/include xxx.c -o xxx -L/usr/local/lib -Wl,-R/usr/local/lib
The -Wl,-R part tells the resulting binary to also look for the library
in /usr/local/lib at runtime before trying to use the one in /usr/lib/.
Try adding LD_LIBRARY_PATH, which indicates search paths, to your ~/.bashrc file
LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/path_to_your_library
It works!
The linux.org reference page explains the mechanics, but doesn't explain any of the motivation behind it :-(
For that, see Sun Linker and Libraries Guide
In addition, note that "external versioning" is largely obsolete on Linux, because symbol versioning (a GNU extension) allows you to have multiple incompatible versions of the same function to be present in a single library. This extension allowed glibc to have the same external version: libc.so.6 for the last 10 years.
cd /home/<user_name>/
sudo vi .bash_profile
add these lines at the end
LD_LIBRARY_PATH=/usr/local/lib:<any other paths you want>
export LD_LIBRARY_PATH
Another possible solution depending on your situation.
If you know that libpthread_rt.so.1 is the same as libpthread_rt.so then you can create a symlink by:
ln -s /lib/libpthread_rt.so /lib/libpthread_rt.so.1
Then ls -l /lib should now show the symlink and what it points to.
I had a similar error and it didn't fix with giving LD_LIBRARY_PATH in ~/.bashrc .
What solved my issue is by adding .conf file and loading it.
Go to terminal an be in su.
gedit /etc/ld.so.conf.d/myapp.conf
Add your library path in this file and save.(eg: /usr/local/lib).
You must run the following command to activate path:
ldconfig
Verify Your New Library Path:
ldconfig -v | less
If this shows your library files, then you are good to go.
running:
sudo ldconfig
was enough to fix my issue.
I had this error when running my application with Eclipse CDT on Linux x86.
To fix this:
In Eclipse:
Run as -> Run configurations -> Environment
Set the path
LD_LIBRARY_PATH=/my_lib_directory_path
Wanted to add, if your libraries are in a non standard path, run ldconfig followed by the path.
For instance I had to run:
sudo ldconfig /opt/intel/oneapi/mkl/2021.2.0/lib/intel64
to make R compile against Intel MKL
All I had to do was run:
sudo apt-get install libfontconfig1
I was in the folder located at /usr/lib/x86_64-linux-gnu and it worked perfectly.
Try to install lib32z1:
sudo apt-get install lib32z1
If you are running your application on Microsoft Windows, the path to dynamic libraries (.dll) need to be defined in the PATH environment variable.
If you are running your application on UNIX, the path to your dynamic libraries (.so) need to be defined in the LD_LIBRARY_PATH environment variable.
The error occurs as the system cannot refer to the library file mentioned. Take the following steps:
Running locate libpthread_rt.so.1 will list the path of all the files with that name. Let's suppose a path is /home/user/loc.
Copy the path and run cd home/USERNAME. Replace USERNAME with the name of the current active user with which you want to run the file.
Run vi .bash_profile and at the end of the LD_LIBRARY_PATH parameter, just before ., add the line /lib://home/usr/loc:.. Save the file.
Close terminal and restart the application. It should run.
I got this error and I think its the same reason of yours
error while loading shared libraries: libnw.so: cannot open shared
object file: No such file or directory
Try this. Fix permissions on files:
cd /opt/Popcorn (or wherever it is)
chmod -R 555 * (755 if not ok)
I use Ubuntu 18.04
Installing the corresponding -dev package worked for me,
sudo apt install libgconf2-dev
Before installing the above package, I was getting the below error:
turtl: error while loading shared libraries: libgconf-2.so.4: cannot open shared object file: No such file or directory
I got this error and I think its the same reason of yours
error while loading shared libraries: libnw.so: cannot open shared object
file: No such file or directory
Try this. Fix permissions on files:
sudo su
cd /opt/Popcorn (or wherever it is)
chmod -R 555 * (755 if not ok)
chown -R root:root *
A similar problem can be found here.
I've tried the mentioned solution and it actually works.
The solutions in the previous questions may work. But the following is an easy way to fix it.
It works by reinstalling the package libwbclient
in fedora:
dnf reinstall libwbclient
You can read about libraries here:
https://domiyanyue.medium.com/c-development-tutorial-4-static-and-dynamic-libraries-7b537656163e
I am working on a project. I've been using a simple editor so far and my own Makefile to build it. I would like to switch to CLion, though.
According to this question you can tell CMake to run your Makefile. So my CMake.txt looks like this:
cmake_minimum_required(VERSION 3.6)
project(rekotrans_testbed_simulator)
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=c++11")
add_custom_target(rekotrans_testbed_simulator COMMAND make -C ${rekotrans_testbed_simulator_SOURCE_DIR} CLION_EXE_DIR=${PROJECT_BINARY_DIR})
It builds fine. I also set the working directory and pointed at the correct executable.
In my project I test using cppunit 1.13. However it can't find the shared library:
/home/kunterbunt/dev/comnets/git-repository/rekotrans-testbed-simulator/rekotrans-testbed-simulator-tests: error while loading shared libraries: libcppunit-1.13.so.0: cannot open shared object file: No such file or directory
LD_LIBRARY_PATH points to
echo $LD_LIBRARY_PATH
/usr/local/lib
and /usr/local/lib contains the library:
ls /usr/local/lib/
libcppunit-1.13.so.0# libcppunit-1.13.so.0.0.2* libcppunit.a libcppunit.la* libcppunit.so# pkgconfig/
ldd shows this:
ldd /home/kunterbunt/dev/comnets/git-repository/rekotrans-testbed-simulator/rekotrans-testbed-simulator-tests
linux-vdso.so.1 (0x00007ffc257e8000)
libboost_thread.so.1.63.0 => /usr/lib/libboost_thread.so.1.63.0 (0x00007f1c73254000)
libboost_system.so.1.63.0 => /usr/lib/libboost_system.so.1.63.0 (0x00007f1c73050000)
libboost_date_time.so.1.63.0 => /usr/lib/libboost_date_time.so.1.63.0 (0x00007f1c72e3f000)
libpthread.so.0 => /usr/lib/libpthread.so.0 (0x00007f1c72c22000)
libboost_program_options.so.1.63.0 => /usr/lib/libboost_program_options.so.1.63.0 (0x00007f1c729a4000)
libdl.so.2 => /usr/lib/libdl.so.2 (0x00007f1c727a0000)
libcppunit-1.13.so.0 => /usr/local/lib/libcppunit-1.13.so.0 (0x00007f1c72563000)
libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00007f1c721db000)
libm.so.6 => /usr/lib/libm.so.6 (0x00007f1c71ed7000)
libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0x00007f1c71cc0000)
libc.so.6 => /usr/lib/libc.so.6 (0x00007f1c71922000)
librt.so.1 => /usr/lib/librt.so.1 (0x00007f1c7171a000)
/lib64/ld-linux-x86-64.so.2 (0x00007f1c7347c000)
So why can't CLion find it? Everything works if I run the binary from console.
Have a look at How to set the environmental variable LD_LIBRARY_PATH in linux:
If you add your custom library path to the LD configuration, then CLion will find your libraries automatically and you don't have to add them to the run configurations.
On Ubuntu/Debian, you can configure LD by creating a new .conf file
sudo nano /etc/ld.so.conf.d/myLocalLibs.conf
that simply contains the path to your libraries: /usr/local/lib. Finally, call
sudo ldconfig
to update the LD configuration.
Note that on some systems (Ubuntu/Debian) you cannot set the LD_LIBRARY_PATH in /etc/profile or /etc/environment:
Since Ubuntu 9.04 Jaunty Jackalope, LD_LIBRARY_PATH cannot be set in
$HOME/.profile, /etc/profile, nor /etc/environment files. You must use
/etc/ld.so.conf.d/*.conf configuration files. See Launchpad bug #366728
for more information.
(help.ubuntu.com)
As oLen correctly pointed out, CLion doesn't seem to start as my user when launched via the GUI (Gnome in my case). I don't know as what it starts, but setting LD_LIBRARY_PATH=/usr/local/lib in /etc/profile and rebooting (or resourcing) it makes it work - in a nutshell the variable wasn't set for whatever user is running CLion.
Another way is Run -> Edit Configurations -> (select your application) -> Environment variables. Here you can manually set LD_LIBRARY_PATH to whatever you need, in my case to /usr/local/lib.
As an alternative to the accepted answer you can go to Run -> Edit Configurations -> Templates, choose CMake Application (and/or Google Test) and set Environment variables: to:
LD_LIBRARY_PATH=/usr/local/gcc-latest/lib64
Any new application created from now on will inherit these settings.
I'm building C++11 with GCC 4.8 on CentOS 6 using "hax", then deploying on arbitrary CentOS 6 targets (on which anything C++-related out of the box will have been built as C++03 with GCC 4.3) (ref).
To make this work, I'm going to ship all of my third-party libs as well as the g++ runtimes, and rpath my executables so the newer libs are assuredly found in the proper place. For the runtimes, by my count I need to ship libstdc++ and libgcc_s. But I need to know where they are on my build system so that I can package them up.
Is there some neat way I can query for their location from within my packaging script?
(If the best approach is too awkward I'll just link them statically, but I'd like to avoid that if I can as my project includes several executables. Also if I were to statically link everything I believe I'd run the risk of GPL-ing my whole project, e.g. by statically linking the MySQL C API via my C++ MySQL wrapper lib. Could do a mixture of both, I suppose, though some sources warn against this…)
For bonus points, do I need to add anything to this list, out of libssl, libcrypto, libm, libpthread, libc, librt, libz and ld-linux-x86-64?
If I understand correctly, you have already built your binaries and just want to get a list of runtime libraries to package them along with binaries? You can try using ldd for this, like:
> ldd /usr/bin/ls
linux-vdso.so.1 (0x00007ffe76dd2000)
libselinux.so.1 => /lib64/libselinux.so.1 (0x00007fc97131f000)
libcap.so.2 => /lib64/libcap.so.2 (0x00007fc97111a000)
libacl.so.1 => /lib64/libacl.so.1 (0x00007fc970f10000)
libc.so.6 => /lib64/libc.so.6 (0x00007fc970b68000)
libpcre.so.1 => /usr/lib64/libpcre.so.1 (0x00007fc970902000)
libdl.so.2 => /lib64/libdl.so.2 (0x00007fc9706fd000)
/lib64/ld-linux-x86-64.so.2 (0x000055c4ba4ed000)
libattr.so.1 => /lib64/libattr.so.1 (0x00007fc9704f8000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fc9702db000)
This way you will see all libraries needed except, of course, the ones that are used via dlopen().
In my Makefile:
GCC_INSTALL_DIR := $(shell $(CXX) -print-search-dirs | grep install | cut -d' ' -f2)
…then my main build target will perform:
ln -sf $(GCC_INSTALL_DIR)/libstdc++.so $(BIN_DIR)/deps/
…and I can dump everything in $(BIN_DIR)/deps into the right place on install.
I think.
Problem: I am building an external project in CMake. The project has a Makefile that ultimately produces a shared object. I want to link against and install this object in my super project, just as if it were one of the libraries in the project. The problem is that the ExternalProject lib is getting linked into my applications and libraries with a relative path, not an absolute path which causes problems when running from any directory besides where CMake puts it.
I have created a sample SSCCE example project to demonstrate my overall setup. Feel free to peruse and compile if needed (git clone https://github.com/calebwherry/cmake-SO-question-main --recursive && cd cmake-SO-question-main && mkdir build && cd build && cmake .. && make && cd src/app/testApp && ldd testApp).
Whenever I run ldd on the executable and libs, I get output like this:
linux-vdso.so.1 => (0x00007fff8b5a2000)
libTestLib.so => /home/jwherry3/repos/cmake-superprj-main-test/build/src/lib/TestLib/libTestLib.so (0x00007f592da57000)
../../lib/libExtLib.so (0x00007f592d855000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f592d539000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f592d2b7000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f592d0a0000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f592cd14000)
/lib64/ld-linux-x86-64.so.2 (0x00007f592dc5a000)
I have tried all kinds of things dealing with RPATHS but can't get the ExtLib to link right. The lib that is local to the project (libTestLib.so) links just fine.
I also tried to set the LD_LIBRARY_PATH to override the relative path when I run the app but even when I do that, it still doesn't find the library. I suppose because it is relative it does not follow the normal linking order? The outcome is that the binary will not run unless I am in the directory where it resides.
I feel like I'm doing something really dumb when creating dependencies with the ExternalProject and that is my issue but I have beat my head for 3 days and haven't come up with anything.
System setup: Debian Wheezy 64-bit, CMake 3.0.2, g++-4.9.2.
Took awhile but I have finally arrived at an answer with help from the CMake Users listserv, specifically #brad-king.
The main issue is that I am not compiling my shared object correctly in my external project. Brad's answer to my question:
Thanks for the complete/simple example. The problem is that
the libExtLib.so file built by the external project does not
have DT_SONAME set by the linker. When a linker is given a
path to a shared library file that has no soname then the path
is copied into the DT_NEEDED field of the consumer since it
has no soname to use for that.
There are two solutions:
Make sure DT_SONAME gets set properly by the external build system.
Tell CMake that the imported library file has no soname:
set_property(TARGET ExtLib PROPERTY IMPORTED_NO_SONAME 1)
CMake will then link it via -lExtLib and the linker will not
store the path to the file in DT_NEEDED but only the file name.
Either of these should resolve the issue. Number 1 is cleaner.
Since I have control over the Make files in the external library, I opted for the cleaner first solution by compiling the shared object like so:
$(SHARED_TARGET): $(OBJECTS)
$(CXX) $(CXXFLAGS) $(OBJECTS) -o $# $(LDFLAGS) -Wl,-soname,$#
I have revised my original example and made it a lot simpler: https://github.com/calebwherry/cmake-SO-question-main. I will leave it up as a reference for anyone stumbling across this post at a later date.
P.S.
There is another fix that is sub-optimal. If I hadn't done any of the above, I could have just given target_link_library the full path to the library I was linking against and not used the imported library target. I have noted this in the CMake file in the repo and commented it out. Not a great solution but does solve the issue another way.
I have a very odd problem with the installation of PCL. Basically i have set up PCL, boost, cmake, flann etc.. it all builds and compiles correctly. I copied and built the ICP example and it builds just fine.
Here is where it gets weird. When I run the application I get the following error:
ldd:FATAL: Could not load library bin.v2/libs/system/build/qcc-4.4.2/
release/threading-multi/libboost_system.so.1.48.0
So libboost_system.so.1.48.0 exists in the /usr/local/lib path and is even linked earlier by the same application, ie. if i run ldd on the application i get the following linked library information:
$ ldd iterative_closest_point
./iterative_closest_point:
libboost_system.so => /usr/local/lib/libboost_system.so.1.48.0 (0xb8200000)
libboost_filesystem.so => /usr/local/lib/libboost_filesystem.so.1.48.0 (0xb8209000)
libboost_thread.so => /usr/local/lib/libboost_thread.so.1.48.0 (0xb8225000)
OTHER BOOST
libpcl_common.so.1.7 => /usr/local/lib/libpcl_common.so.1.7.1 (0xb82ea000)
libpcl_octree.so.1.7 => /usr/local/lib/libpcl_octree.so.1.7.1 (0xb838c000)
OTHER PCL
libstdc++.so.6 => /usr/qnx650/target/qnx6/x86/lib/libstdc++.so.6.0.13 (0xb9285000)
libm.so.2 => /usr/qnx650/target/qnx6/x86/lib/libm.so.2 (0xb8774000)
libc.so.3 => /usr/lib/ldqnx.so.2 (0xb0300000)
ldd:FATAL: Could not load library bin.v2/libs/system/build/qcc-4.4.2/release/threading-multi/libboost_system.so.1.48.0
So I did some investigation into what the hell PCL is looking for, what is bin.v2? It exists in the boost install directory????
Now here is where it just gets nuts, if i run the program with an absolute path from the boost install directory ie. where the bin.v2 folder exists:
qnx:/root/boost/boost_1_48_0# /root/experiments/checkPCL/iterative_closest_point
it works!! the program outputs the desired things. So i was like alright, lets run ldd here:
qnx:/root/boost/boost_1_48_0# ldd /root/experiments/checkPCL/iterative_closest_point
and we get this:
libboost_system.so => /usr/local/lib/libboost_system.so.1.48.0 (0xb8200000)
MORE BOOST
libpcl_common.so.1.7 => /usr/local/lib/libpcl_common.so.1.7.1 (0xb82ea000)
MORE PCL
libstdc++.so.6 => /usr/qnx650/target/qnx6/x86/lib/libstdc++.so.6.0.13 (0xb9285000)
libm.so.2 => /usr/qnx650/target/qnx6/x86/lib/libm.so.2 (0xb8774000)
libc.so.3 => /usr/lib/ldqnx.so.2 (0xb0300000)
libboost_system.so.1.48.0 => /root/SMG/extern/libs/boost/boost_1_48_0/bin.v2/libs/system/build/qcc-4.4.2/release/threading-multi/libboost_system.so.1.48.0 (0xb87a7000)
libbz2.so.1.0.4 => /usr/lib/libbz2.so.1.0.4 (0xb87b0000)
libz.so.2 => /proc/boot/libz.so.2 (0xb87c2000)
The big long one is an absolute link into the boost filepath. I dont understand how PCL or ldd or anything could know about this path.
Does anyone have any ideas about how this could have happened? Also I need some solutions on how to fix it.
EDIT + ADD:
So recently, i am not sure what has changed but i have started to get the linker warning (not error):
/usr/qnx650/host/qnx6/x86/usr/bin/ntox86-ld: warning: bin.v2/libs/system/build/
qcc-4.4.2/release/threading-multi/libboost_system.so.1.48.0, needed by
/usr/local/lib/libboost_filesystem.so, not found (try using -rpath or -rpath-link)
so for whatever reason this is definitely attempting to link to bin.v2/.../... which is absolutely nuts, i have never seen this before? I have now scoured the boost install directory looking for things that might caused this. Nothing is unusual about how boost is installed.
As a further note i have made a simple example, a program that has main, includes and prints "it works", it has the following CMakeLists.txt:
find_package(PCL 1.2 REQUIRED)
find_package(Boost 1.48.0 COMPONENTS system filesystem REQUIRED)
add_executable (test test.cpp)
target_link_libraries(test
${BOOST_FILESYSTEM} #Works
${PCL_DEFINITIONS} #Works
${PCL_SEARCH_LIBRARIES} #If i add this it fails!
)
So it seems like PCL and boost are interacting badly and causing some truly crazy behavior!
This may not be of help but I have the same problem and here is what I found. That path is used by some boost libraries.
objdump -x libbost_filesystem-qcc-mt-1_55.so will show:
Dynamic Section:
NEEDED bin.v2/libs/system/build/qcc/release/threading-multi/libboost_system-qcc-mt-1_55.so.1.55.0
NEEDED libm.so.2
NEEDED libstdc++.so.6
NEEDED libc.so.3
INIT 0x00004d40
Notice the full path.
I came upon this post while looking for a solution to this problem. I'm pretty sure it's a boost build related issue though, I'm also using QNX.
If it works from the absolute directory that contains bin.v2/libs/system/build/qcc-4.4.2/release/threading-multi/ then probably you have
set LD_LIBRARY_PATH set to include . (the current working directory)
added the current work directory using ldconfig somehow (there's several ways)
This is a bad idea in general. It's especially a bad idea if you're running as root (which it seems you do) because it can be exploited as a security hole.
The real issue would still appear to be that the linker embeds the full path for libboost_system. I don't know what causes this, but perhaps
you specify the library as a concrete source (libboost_system.so.1.48.0 in stead of -lboost_system on most linkers/compilers)
it is some kind of linker option (like -rpath?)
Hope this helps