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 have to preparae a script that
-switches the current Java to this one: /usr/bin/java
export PATH=$JAVA_HOME”$PATH” export JAVA_HOME=”/usr/bin/java”
What should I add to it to work?
/usr/bin/java is not a directory, but an executable file.
The JAVA_HOME should point to Java's installation directory, if at all required. Most of the time, you don't actually need to define JAVA_HOME as it's only used by certain applications (such as Maven) to override the version of Java that would otherwise be found on the PATH.
So all you need to do is:
export PATH=/usr/bin:$PATH
and this will make the java command be taken from the /usr/bin directory. This is normally in your path anyway, but this line ensures it's at the start.
You may also need to delete any existing definition of the JAVA_HOME variable, as that would override /usr/bin/java when used by tools such as Maven.
Same to this one but still didn't figure out. tried all solution....
Maven error: Could not find or load main class org.codehaus.plexus.classworlds.launcher.Launcher
OS: Windows 7
Installed Maven 3.3.3 from ftp://mirror.reverse.net/pub/apache/maven/maven-3/3.3.3/binaries/apache-maven-3.3.3-bin.zip
Environment variable:
Path = C:\Tools\apache-maven-3.3.3\bin
M2_HOME = C:\Tools\apache-maven-3.3.3
Error:
$ mvn
Error: Could not find or load main class
org.codehaus.plexus.classworlds.launche r.Launcher
I guess this error caused because of downloading SRC instead of BINARY from Maven site. Please make sure to download Binary zip.
I've solved the error by downloading the bin file from maven, not the src file, and then the path pointing to the bin directory
Step1: Install ApacheMaven Binary-tar.gz archive file
Step2: Add C:\Program Files\apache-maven-3.5.2\bin to the PATH under user variables
Step3: In command prompt, run mvn -v
Change M2_HOME by MAVEN_HOME. It worked for me on Windows 7.
This fixed mine, taken from
use M3 home
I had this little issue on my Mac after installing maven3 and jdk1.7. Here is what fixed my issue:
Remove the M2_HOME variable from the path.
Add M3_HOME variable with the path to your maven 3 installation.
Here is the interesting part: I use symbolic links for versioning. The values of both M2_HOME and M3_HOME were identical. Both were /Developer/maven. Hence it appears that the name M2_HOME in place of M3_HOME is what actually causes the issue. I leave it as an exercise (that I may return to) to find the issue in the source.
This means maven is not properly configured.
There is a chance that you might have downloaded wrong zip file or incomplete file.
Once you are sure the file is correct and unzipped, in windows, go to command prompt,go to bin,and try to execute the mvn.bat file. The error originates from that file.If it is executing nothing to worry.
Avoid setting MAVEN_HOME.Its not needed. Set the maven bin only in the PATH
Remove & disable the M2_HOME in the /etc/environment using the unset function as in
unset M2_HOME
I am following Joseph Adler instructions on how to install ( page 555 here - http:// it-e
books. info/book/1014/ ) Hadoop on my lubuntu.
I wrote in terminal:
wget http://archive.cloudera.com/cdh/3/hadoop-0.20.2-cdh3u4.tar.gz
tar xvfz hadoop-0.20.2-cdh3u4.tar.gz
and everything went fine, .tar.gz file was downloaded and then it was untarred.
But when I wrote
hadoop version
in the terminal, there appeared a message saying that there is no command hadoop.
Does anybody has an idea on what should I do to use (already) installed but (still) somehow invisible Hadoop?
Thanks for help!
In Linux invoking a command without prefixing its path requires the location where the command resides should be present the environment variable PATH.
Here, For executing the command you got to specify either absolute or relative path of the command. Following can be used, replace with the extracted location.
<EXTRACT_LOC_PATH>/hadoop-0.20.2-cdh3u4/bin/hadoop version
If your present working directory is /hadoop-0.20.2-cdh3u4/bin/ then ./hadoop version would be sufficient.
Whenever you are getting COMMAND NOT FOUND ERROR the problem will be there in .bashrc file only. You might not have properly set the JAVA_HOME, HADOOP_HOME and PATH Variable. So check it out whether you have given proper path for all these 3 variables or not.
I am getting below error when taking checkout from svn using a script.
**[Test] $ /bin/sh -xe /tmp/hudson8576425899836211909.sh
+ sh /cvsrx/rxapp/build_dir/Jenkins_Scripts/test.sh
Could not load program svn:
Could not load module /opt/freeware/lib/libssl.so.
Dependent module /usr/lib/libcrypto.a(libcrypto.so.1.0.1) could not be loaded.
Member libcrypto.so.1.0.1 is not found in archive
Could not load module svn.
Dependent module /opt/freeware/lib/libssl.so could not be loaded.
Could not load module .
Build step 'Execute shell' marked build as failure
Finished: FAILURE**
In test.sh I have written just one line svn co /path to svn branch/
I am in middle of some test so please don't ask why am not using jenkins in build svn plugin.
here,I am able to take checkout on command prompt using svn co /path to svn branch/
But not if I write this command line in script and run in execute shell of jenkins.
Any help please ?
Am using jenkins on AIX 7 platform.
I had softlinks from /usr/bin/svn to /opt/freeware/bin/svn.SVN installed at /opt/freeware/bin/svn ..... By default when i do which svn its showing /usr/bin/svnBut When i deleted those softlinks and exported path,Jenkins didnt recognize SVN at all.And which svn command doesnot show any svn installed . PFB logs of jenkins :
`
/bin/sh -xe /tmp/hudson5607872610124977868.sh
+ export PATH=/opt/freeware/bin/svn/:/opt/freeware/bin/svnversion:/opt/freeware/bin/svn:/opt/freeware/bin/svnversion/:/usr/java5/lib:/opt/freeware/bin/svnversion/bin:/usr/local/bin:/usr/bin:/usr/X11R7/bin:/bin:/usr/games:/opt/gnome/bin:/opt/kde3/bin:/usr/lib/mit/bin:/sbin:/
+ echo /opt/freeware/bin/svn/:/opt/freeware/bin/svnversion:/opt/freeware/bin/svn:/opt/freeware/bin/svnversion/:/usr/java5/lib:/opt/freeware/bin/svnversion/bin:/usr/local/bin:/usr/bin:/usr/X11R7/bin:/bin:/usr/games:/opt/gnome/bin:/opt/kde3/bin:/usr/lib/mit/bin:/sbin:/opt/freeware/bin/svn/:/opt/freeware/bin/svnversion:/opt/freeware/bin/svn:/opt/freeware/bin/svnversion/:/usr/java5/lib:/opt/freeware/bin/svnversion/bin:/usr/local/bin:/usr/bin:/usr/X11R7/bin:/bin:/usr/games:/opt/gnome/bin:/opt/kde3/bin:/usr/lib/mit/bin:/sbin
+ cd /usr/local/apps/Jenkins_new/scripts
+ ./test.sh
Could not load program /opt/freeware/bin/svn:
Could not load module /opt/freeware/lib/libssl.so.
Dependent module /usr/lib/libcrypto.a(libcrypto.so.1.0.1) could not be loaded.
Member libcrypto.so.1.0.1 is not found in archive
Could not load module svn.
Dependent module /opt/freeware/lib/libssl.so could not be loaded.
Could not load module .
./test.sh[3]: svn: not found
Build step 'Execute shell' marked build as failure
Finished: FAILURE`
ReInstalling Jenkins solved my problem !! It was due to corrupt plugin which happened due to server restart.
Thanks Everyone
I have not seen the exact command of svn you have used in test.sh, but would advice you to give full path of SVN in your calling line, eg /usr/bin/svn co .....
And if also possible make an entry in your test.sh for export PATH and export LD_LIBRARY_PATH setting them to values which are paths of the mentioned .so files
I see you're using Hudson/Jenkins. Hudson and Jenkins use SVNKit internally when checking stuff in and out of Subversion. This means that the command line svn client may not be installed on your system, or that it may have other problems.
It is also possible that there are multiple svn clients on your system. For example, you may have one under /usr/bin/svn and one under /usr/local/bin/svn. If Subversion is working from the command line, but not in the script, you may have a different $PATH setup when you're executing from the command line vs. the script from Hudson/Jenkins. You can add to your script (if it's BASH) the line type svn to see where your executing svn from. It may be different from what you are using from the command line. It may also be nice to print out $PATH as part of your script.
It would also be helpful to see the svn command that your script is executing, and tell us what you're trying to do. You can also add to your script the following lines:
PS4="\$LINE: "
set -xv
These lines will turn on shell script debugging, and help you locate where your script is having problems.
This will give you some clues as to what is going wrong in your script.
Reply
Thanks David. Here only 1 svn path exists (usr/bin/svn)but created as a softlink see -->cd /usr/bin/svn lrwxrwxrwx 1 root system 26 Jul 1 14:34 svn -> ../../opt/freeware/bin/svn. Also soflink of libs.so is created see --> lrwxrwxrwx 1 root system 15 Sep 13 18:15 libssl.so -> libssl.so.1.0.1 .......... Is it possible that softlink is creating these problems ?? Before requesting to remove these softlinks ,i need confirmation that these softlinks are creating problems.
Softlinking isn't unusual for Unix. For example, I have Ant, Grails, Maven, Subversion, and many other packages installed under /opt on my Mac. In order not to have to include each and every one of these in my path, I soft link all of the binaries for those programs under /usr/local/bin. About 80% of the programs under /usr/local/bin are merely soft links elsewhere.
Library soft links are also very common. This usually has to do with version numbering. When a program requests a library, it may or may not include the library's version number. So, you have libfoo-2.0.3.so on your drive. This is the actual version of foo. However, few programs will request that particular version. Instead, they may simply request they need Version #2 of foo or just say they need to link to foo.
To handle this, you will have libfoo2.0.3.so soft linked to libfoo-2.so for programs that specify they need version 2 of foo. Then, libfoo-2.so will be soft linked to libfoo.so. This way, libfoo will be called no matter what. If I install, libfoo2.0.4.so, I can change the link to libfoo-2.so to point to version 2.0.4 instead of version 2.0.3, and anything that depends upon Foo will be picking up the correct version.
Instead, let's look at the error message:
Could not load module /opt/freeware/lib/libssl.so.
Dependent module /usr/lib/libcrypto.a(libcrypto.so.1.0.1) could not be loaded.
Member libcrypto.so.1.0.1 is not found in archive
For some reason, it couldn't access the file /usr/lib/libcryto.a. Is this file on you machine? Is it in /usr/lib? If not, where is it located?
So, where did you get this version of Subversion from? Why is the link to the /opt/freeware/bin/ directory? Was this part of your system?
It could be that Subversion on your system is not complete and never did work. In Jenkins, the Subversion repository is accessed by the SVNKit Jarfile which is embedded inside Jenkins/Hudson itself, so it wouldn't really be a surprise to find that the Subversion binary didn't work.
Are you able to do anything with Subversion from the command line? If not, you may have to install a new version of Subversion from Perzl which is where CollabNet points to for an AIX version of Subversion. (It's at least up to date at version 1.8.4).
You may even want to change the soft link at /usr/bin/svn to point to the newer, working version of Subversion.