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 used rm -rf to delete the gcc5.3.0, but mac continues to use gcc5.3.0.
The wrong message:
g++: error trying to exec 'cc1plus': execvp: No such file or directory
What should I do to reuse apple-gcc42?
Editing comments and responses into an answer.
Where was GCC 5.3.0 installed? Where did it come from? Did you create it or is it from Apple, or one of the auxilliary packagers? Did your recursive remove actually remove anything? Does running xcode-select help? (Use man xcode-select to see what it does; maybe xcode-select --install is useful, but I'm not sure since I've never destroyed my compilation system like that.) Which version of XCode do you have installed? Which version of Mac OS X are you running?
GCC5.3.0 is installed at /usr/local/libexec/gcc/x86_64-apple-darwin15.0.0/5.3.0. I removed the folder gcc. My Mac OS X is 10.11.6 and my Xcode is 7.3.1.
Removing /usr/local/lib/libexec/gcc didn't remove the executables from /usr/local/bin, so when you run g++, the shell is still finding the executable /usr/local/bin/g++, but that is not finding its auxilliary programs because you did manage to remove them. You also haven't cleaned up the headers that were installed under /usr/local/include, etc. Don't use rm -fr; it is crude and only partially effective when you have to uninstall complex suites of software like GCC. You could also use /usr/bin/g++ instead of g++.
So what should I do now?
You need to finish the removal job — remove gcc and g++ from /usr/local/bin at minimum. That should leave you with /usr/bin/gcc and /usr/bin/g++ as the compilers. You might have to run hash -r or start a new terminal window to avoid Bash's caching of the location of the compiler (but you'd get bash: /usr/local/bin/g++ not found or something similar as an error message).
Thank you. This works for me!
I know that this should probably be very easy, and I have looked into the read me files and other files in cgdb like INSTALL that talk about isntalling cgdb. I was trying to install cgdb and the instructions said:
$ ./configure --prefix=/usr/local
$ make
$ sudo make install
However, there is no such file inside of the file I got from running the git clone command. i.e. from running:
$ git clone git://github.com/cgdb/cgdb.git
I went inside that file to see the installation instructions and it says the following:
Basic Installation
==================
These are generic installation instructions.
The `configure' shell script attempts to guess correct values for
various system-dependent variables used during compilation. It uses
those values to create a `Makefile' in each directory of the package.
It may also create one or more `.h' files containing system-dependent
definitions. Finally, it creates a shell script `config.status' that
you can run in the future to recreate the current configuration, a file
`config.cache' that saves the results of its tests to speed up
reconfiguring, and a file `config.log' containing compiler output
(useful mainly for debugging `configure').
If you need to do unusual things to compile the package, please try
to figure out how `configure' could check whether to do them, and mail
diffs or instructions to the address given in the `README' so they can
be considered for the next release. If at some point `config.cache'
contains results you don't want to keep, you may remove or edit it.
The file `configure.in' is used to create `configure' by a program
called `autoconf'. You only need `configure.in' if you want to change
it or regenerate `configure' using a newer version of `autoconf'.
The simplest way to compile this package is:
1. `cd' to the directory containing the package's source code and type
`./configure' to configure the package for your system. If you're
using `csh' on an old version of System V, you might need to type
`sh ./configure' instead to prevent `csh' from trying to execute
`configure' itself.
Running `configure' takes awhile. While running, it prints some
messages telling which features it is checking for.
2. Type `make' to compile the package.
3. Optionally, type `make check' to run any self-tests that come with
the package.
4. Type `make install' to install the programs and any data files and
documentation.
5. You can remove the program binaries and object files from the
source code directory by typing `make clean'. To also remove the
files that `configure' created (so you can compile the package for
a different kind of computer), type `make distclean'. There is
also a `make maintainer-clean' target, but that is intended mainly
for the package's developers. If you use it, you may have to get
all sorts of other programs in order to regenerate files that came
with the distribution.
and there is more I didn't paste.
The part that confuses me is the following paragraph:
The file `configure.in' is used to create `configure' by a program
called `autoconf'. You only need `configure.in' if you want to change
it or regenerate `configure' using a newer version of `autoconf'.
does it mean I should run ./configure.in? I am honeslty a little scared of running it because I need to run it in as sudo plus, that file doesn't even exit in the code I got from git clone. This is what I do have in that directory:
➜ cgdb git:(master) ls
AUTHORS Makefile.am autogen.sh doc roadmap.txt
COPYING NEWS autorelease.sh indent.sh test
ChangeLog README cgdb lib
FAQ README.md config packages
INSTALL TODO configure.init release-todo.txt
➜ cgdb git:(master)
I did grep for config or config.in in that directory and it didn't yield anything useful.
I have also tried brew installing it but I ran into problems. When I cgdb the file and hit run it frozen at a print statment instead of moving on to the next command prompt for gdb as in (gdb). Anyone knows whats up? Is it because I am using go source file?
What have people done to have cgdb working on a mac?
Неу, yeah, the git source for cgdb doesn't come with the configure script pre-built. (The official release distributions do, however.)
If you have the right tools installed, you can fix this by running:
./autogen.sh
This will generate the configure script, and then you can install it as you would any other autoconf-based source package.
Forget about all that aggro with configuration and dependency libraries; install MacPorts and do:
$ sudo port install cgdb
They have 0.6.7 at the time of writing.
What worked for me was doing:
brew install cgdb
However, for me that was not enough to get it going. I needed to sudo it for it to run:
sudo cgdb
I would have never guessed I needed to sudo it...I figured it out because it was throwing me the error talked about in the following question:
gdb fails with "Unable to find Mach task port for process-id" error
When using homebrew to install graphviz, the script gets to the point of "Making install in tkstubs" and then throws the following fatal error:
In file included from tkStubLib.c:15:
/usr/include/tk.h:78:11: fatal error: 'X11/Xlib.h' file not found
#include <X11/Xlib.h>
I have installed XQuartz as X11 has been dropped in Mountain Lion, but I'm unsure if it is installed correctly. The location of Xlib.h is:
/opt/X11/include/X11/Xlib.h
There are also two symlinks to /opt/X11, they are:
/usr/X11
/usr/X11R6
Does this look like the correct setup to you? I've never dealt with X11 or XQuartz until yesterday.
Cheers.
After installing XQuartz you may add a symlink to your X11 installation folder by just entering
ln -s /opt/X11/include/X11 /usr/local/include/X11
in terminal. That will fix the problem as well without changing any ruby script.
You need to tell the tkstubs build (and possibly other bits in the package as well) to look for headers in /opt/X11/include; this is not on the standard include path.
Usually this is achieved by passing -I/opt/X11/include as an additional compiler flag, the method to do so is however dependent on the build system.
For reasonably modern configure scripts, the best approach is to pass it in the environment variable CPPFLAGS; if the package uses another build system or this doesn't work for another reason, then you need to look at the Makefile in the build directory.
You can enter in your shell before the compile/link (or brew) command:
export CPPFLAGS=-I/opt/X11/include
The export line will tell the compile/linker to look in /opt/X11/include for the X11 include files
Had the same issue and running this command on terminal
xcode-select --install
worked for me. Run this command after installing xQuartz.
If you need this to work in your CMake builds:
if(APPLE)
include_directories(AFTER "/opt/X11/include")
endif()
That worked well for me.
I got it to install by copying the x11 header file directory to the /opt/local/include directory. Probably not the best way to work around it but quick and easy.
I found this thread while trying to compile ffmpeg from source on OS X. I needed --enable-x11grab and the homebrew build does not support this option.
I had XQuartz installed already but I kept getting errors from ./configure: ERROR: Xlib not found. I thought the answers here would solve my problem, but they did not!
So, if anyone is ever in the same boat, my solution was this:
I opened up the generated config.log and found lots of errors referring to various includes and header files, including X11/Xlib.h - this is misleading. At the very bottom of the logfile was the key, pkg-config was complaining about looking for xbc.pc, and requested that it be put on the path. However, the error message that is displayed on the terminal says nothing about pkg-config or xbc!
The solution is to add to your PKG_CONFIG_PATH environment variable. Mine was nonexistent, so I just did export PKG_CONFIG_PATH=/opt/X11/lib/pkgconfig/ (the folder where I found xbc.pc).
I reran configure and everything worked like a charm!
TL;DR: check config.log - don't trust the terminal output!
Since the make file is looking for X11/xlib.h i.e., it is looking for X11 folder in the current directory, one way to solve this problem is to simply copy the /opt/X11/include/X11 directory to the directory that contains make file.
I've searched for this (exact) error, but I can't find any mention of it on the web.
Basically, I'm trying to install ctags (I've never used it before) on OSX Snow Leopard. Here's what I've done:
I downloaded the latest source package (version 5.8) from here: http://ctags.sourceforge.net/
Per the INSTALL instructions, I've run configure/make/make install. This installs a ctags binary to /usr/local/bin/.
If I cd into /usr/local/bin/ and run ./ctags (with no args), I get this: ctags: Unknown option: -p
Has any one seen this before? I'm obviously not supplying any arguments; if I do, I still get the same error (no matter what the arguments are).
Cheers,
-Lars
I think you should check your ~/.ctags (or any other ctags configuration file listed in ctags -V).
You probably have something like -python-kinds=-i ; ctags interprets that as a single character (-p) option.
In any case, try to run ctags with ctags --options=NONE ; if it fixes the issue, it means that the problem comes from one of your conf files.