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'm not really experienced with graphics programming, but I got curious. I installed both libgtk-3-dev and gtk-3-examples on my Debian 10.7 machine. From there I listed the example package files using dpkg-query -L gtk-3-examples to find some example programs.
In the examples directory I found the following README file:
== Building the examples ==
The examples in this directory are built alongside the rest of GTK+.
The examples under the `application[1-10]` directories are also included in
the GTK+ API reference documentation, and can be built independently, using
the system libraries, by doing:
$ cd application1
$ make -f Makefile.example
Looks straight forward. However, following the directions exactly yields the following result:
make: Makefile.example: No such file or directory
make: *** No rule to make target 'Makefile.example'. Stop.
There are no "Makefile.example" files in the application folders. Running find -name "Makefile*" in the examples directory yields:
./application7/Makefile.in.gz
./application7/Makefile.am
./Makefile.in.gz
./application5/Makefile.in.gz
./application5/Makefile.am
./bp/Makefile.in.gz
./bp/Makefile.am
./application9/Makefile.in.gz
./application9/Makefile.am
./application6/Makefile.in.gz
./application6/Makefile.am
./application2/Makefile.in.gz
./application2/Makefile.am
./application10/Makefile.in.gz
./application10/Makefile.am
./application3/Makefile.in.gz
./application3/Makefile.am
./application1/Makefile.in.gz
./application1/Makefile.am
./application8/Makefile.in.gz
./application8/Makefile.am
./application4/Makefile.in.gz
./application4/Makefile.am
./Makefile.am
I've not had any luck building an example program using the above files. I'm guessing it is because of my unfamiliarity with auto tools? Is there an easy way to build an example GTK program using the above files or do I need know a lot more about make/autotools/configure to get a working example running?
Update:
The cant-run-makefile-am-what-should-i-do post is informative but does not provide a course of action when no configure, bootstrap, or autogen programs can be found within the package. The following command yields no results when executed in my examples directory: find -type f | grep -i -E "*conf*|*auto*|*boot*". I need one of those files to be provided in order to have a successful build (as far as I understand it anyway).
Sorry for the fuss! I'm used to installing regular packages and missed that I needed to download the full source code to get the examples working. So, originally I mentioned that I installed both libgtk-3-dev and gtk-3-examples. I did so using apt-get install libgtk-3-dev && apt-get install gtk-3-examples.
However, to build GTK along with its examples locally it looks like what you want to do is get the source package archive with apt-get source gtk-3-examples (or similar.. I think it actually picked a different meta-package for me when I ran that command).
Then, in my new gtk+3.0-3.24.5 directory there's a nice configure binary that I can run (with subsequent make and make install commands) which produce many files including example program binaries.
So with ./gtk+3.0-3.24.5/examples/application1/exampleapp I get a running example. Voila!
I hit this error message while trying to build gnote using GNU Autotools.
I had first run:
$ git clean -xf # to clean the tree of untracked files, then
$ autoreconf # to create the script named `configure`, and finally
$ ./configure # to check my system, and create Makefiles from their templates
Neither po/Makefile.in.in nor po/Makefile.in exist in the source tree that I downloaded.
Yet configure needs to make this po/Makefile, as called for in the root Makefile.am in this line:
SUBDIRS = data src po help
Where do I get, or how do I make, po/Makefile.in.in?
Like all Gnome related packages, gnote uses many steps of buildsystem setup beyond just running autoreconf.
The autogen.sh script gnote comes with should run all the required steps to set up the buildsystem.
As usual, run the autogen.sh script with the --help parameter if you want to call configure separately.
po/Makefile.in.in is created by running intltoolize from the intltool package. It needs to be run from the project tree's root directory.
There isn't much documentation on intltoolize that I could find except for the brief man page, but it's source code says that that it's a fork of an older utility called libtoolize, and it's a relatively short script.
(BTW, if you don't already have intltoolize installed, you can figure out which package installs it, with this: sudo apt-file find intltoolize.)
*.in files are templates used by AutoMake to create a Makefile.
.in.in is a soft link to /usr/share/intltool/Makefile.in.in.
I'm trying to compile a code to run in parallel on a supercomputer. I know that others have compiled this code to run on the same computer, but for some reason I am having trouble even when using the same methodology as them. For now I'm just trying to compile the code to run in serial as that should be easier to troubleshoot.
configure seems to work correctly.
However make install returns the following:
> make install
CDPATH="${ZSH_VERSION+.}:" && cd .. && /bin/sh /home1/username123/code123/config/missing aclocal-1.13 -I ./config -I /home1/username123/code123/build-tools/aclocal -I /usr/local/share/aclocal
aclocal-1.13: error: couldn't open directory '/usr/local/share/aclocal': No such file or directory
Makefile:534: recipe for target '../aclocal.m4' failed
make: *** [../aclocal.m4] Error 1
aclocal is indeed not located at /usr/local/share/aclocal, it is located at /usr/bin/aclocal - but as /usr/bin is in my path, I don't understand why the location is an issue.
As has been made clear in comments on the question, the problem was that the project sources were copied onto the target system in a way that failed to preserve their original timestamps. The Autotools, through make, use file timestamps to determine which files are out of date, and in particular, Autools-generated Makefiles contain rules for rebuilding the build system itself that can be triggered this way.
It is not ordinarily necessary or desirable to rebuild an Autotools project's build system, except in conjunction with actually performing maintenance on it. It is often the case, in fact, that the necessary support for that is not available locally. To avoid the build system thinking that it needs to rebuild itself, it is important to preserve the file timestamps from the distribution archive. For some packages, it also works to pass the --disable-maintainer-mode argument to the configure script, but by no means do all Autotools configure scripts support that.
The archive extraction tools for the typical archive formats in which Autotools-based packages are distributed do, by default, preserve timestamps when unpacking, so the ordinary procedure of
unpack the archive on the target system (e.g. tar xzf foo-1.2.3.tar.gz)
change to the unpacked source directory (e.g. cd foo-1.2.3)
configure; make; make install
normally does the right thing. Substituting something else for (1), however, such as copying the unpacked source tree from somewhere else, may cause the package to think it needs to rebuild the build system. If that works correctly then it's no big deal, but it is not uncommon that it doesn't. That's what happened here, and following the standard procedure described above solved the problem.
I am relatively new to the Cygwin program, and I have a .sh file that I need to edit and execute. I am currently running on Windows 10. I have installed Cygwin64 terminal on my machine.
The full list of steps required are as follows:
Be sure to have libtool installed.
Download protobuf from https://github.com/google/protobuf/ (download ZIP and unZIP at desired location, or clone the repo) The protocol buffer is used for communication between the CuraEngine and the GUI.
Before installing protobuf, change autogen.sh : comment line 18 to line 38 using #s. This removes the dependency on gtest-1.7.0.
Run autogen.sh from the protobuf directory: $ ./autogen.sh
$ ./configure
$ make
$ make install # Requires superused priviliges.
(In case the shared library cannot be loaded, you can try "sudo ldconfig" on Linux systems)
Once I get to 3.:
Before installing protobuf, change autogen.sh : comment line 18 to line 38 using #s. This removes the dependency on gtest-1.7.0.
I am having issues opening up to .sh file in Cygwin to make the appropriate edit.
When I try this command to even execute the .sh file:
$ '/cygdrive/c/Users/Thomas/Desktop/3D Printing/protobuf-master/autogen.sh'
I receive the error:
Could not find source code. Make sure you are running this script
from the root of the distribution tree.
If anyone has some insight as to a solution for this problem it would be greatly appreciated.
You are getting the error from this test in autogen.sh :
# Check that we're being run from the right directory.
if test ! -f src/google/protobuf/stubs/common.h; then
cat >&2 << __EOF__
Could not find source code. Make sure you are running this script from the
root of the distribution tree.
__EOF__
In this test, common.h path is relative to the protbuf install directory, just cd to it before executing the script.