I apologize if this seems basic but I'm new to linux and not really sure how to proceed. My current git version is 1.7.1 and is located in /usr/bin/git but a newer version of git (1.8) is now available in /usr/src/git/bin/git. How do I make git use this version by default as opposed to the 1.7.1 version?
You have to make sure to call the right executable. This can ben done by explicitly calling /usr/src/git/bin/git instead of git. Of course this would be annoying to type all the time, so you can either make git an alias for that path by adding the line
alias git=/usr/src/git/bin/git
to your .bashrc, or add the directory /usr/src/git/bin to your binary search path by adding the line
export PATH="/usr/src/git/bin:$PATH"
To test that the other git installation searches for the core binaries in the right place, you can check the output of git --exec-path.
My OS (Ubuntu 12.04) comes with a pre-packaged Qt4 libraries and other relevant stuffs. But I wanted to use the latest vanilla Qt 5.2.1, I have installed it and it's working fine, suppose I have compiled this framework which depends on Qt.
What I had to do is to add the Qt 5.2.1 libraries to the $LD_LIBRARY_PATH. My Qt 5.2.1 home path is /opt/Qt5.2.1/5.2.1/gcc_64, and thus my $LD_LIBRARY_PATH contains /opt/Qt5.2.1/5.2.1/gcc_64/lib (and /opt/Qt5.2.1/Tools/QtCreator/lib for qtcreator related stuffs)
However, recently I am trying to compile the latest gnu octave. It's configure script looks for the Qt cflags (i.e. -l/-I/-L flags) by invoking the pkg-config.
What I came to know that pkg-config looks for the appropriate .pc files to get the exact information related to all compilation/linking flags. My system (Ubuntu) maintains a list of all required .pc file locations in /var/lib/dpkg/info/pkg-config.list. But I do not have any $PKG_CONFIG_PATH environment variable on Ubuntu 12.04 (I am not sure why).
My newly installed Qt5 has a set of .pc files in /opt/Qt5.2.1/5.2.1/gcc_64/lib/pkgconfig/.
So, how do I make pkg-config to recognize the development libraries in the newly installed Qt 5.2.1 ?
I know that this could be solved by just installing the Qt4 -dev packages from the Ubuntu repo, but I do not want to do that. I need the vanilla Qt 5.2.1 for other purposes.
NOTE:
I have added the the path /opt/Qt5.2.1/5.2.1/gcc_64/lib/pkgconfig/ to the pkg-config.list but the pkg-config does not update the compilation flags accordingly.
Adding the path (/opt/Qt5.2.1/5.2.1/gcc_64/lib/pkgconfig/) to $PKG_CONFIG_PATH does not work as well.
Here is the octave configure script output.
This problem is because Octave is searching for QtCore.pc, QtGUI.pc, and QtNetwork.pc but Qt5 seems to have renamed them as Qt5Core.pc, Qt5GUI.pc, and Qt5Network.pc. One solution is to create symlinks for them:
cd /opt/Qt5.2.1/5.2.1/gcc_64/lib/pkgconfig/
ln -s ./Qt5Core.pc ./QtCore.pc
ln -s ./Qt5GUI.pc ./QtGUI.pc
ln -s ./Qt5Network.pc ./QtNetwork.pc
cd octave_build_dir
export $PKG_CONFIG_PATH="/opt/Qt5.2.1/5.2.1/gcc_64/lib/pkgconfig/"
./configure # with fingers crossed
I am unsure of the why the reason of name change. I wonder if there should be some sort of mechanism in place where the unversion versions would be in the $PKG_CONFIG_PATH, and changing your preferences would change the link to correct version.
Finally, your config.log and config.status would have been more useful than just the output of configure. The mentioned files will have the actual commands and output of your configure.
The carandraug's answer is correct, but I didn't need to symlink .pc files(Qt 5.9.5). To prevent removing other pkg-config addresses, export PKG_CONFIG_PATH like below:
PKG_CONFIG_PATH=$PKG_CONFIG_PATH:/opt/Qt5.2.1/5.2.1/gcc_64/lib/pkgconfig/
And to execute it at startup and systemwide(no need to export in every terminal session), put these lines at the bottom line in ".bashrc":
PKG_CONFIG_PATH=$PKG_CONFIG_PATH:/opt/Qt5.2.1/5.2.1/gcc_64/lib/pkgconfig/
export PKG_CONFIG_PATH
I am using Debian OS and I'm trying to point to cmake where is my Qt4.
I try to build qjson library and with its CMakeLists.txt:
http://pastebin.com/fKNp0Qgy
I get:
Qt5 not found, searching for Qt4
qmake: could not exec '/usr/lib/x86_64-linux-gnu/qt4/bin/qmake': No such file or directory
CMake Error at /usr/share/cmake-2.8/Modules/FindQt4.cmake:1386 (message):
Found unsuitable Qt version "" from NOTFOUND, this code requires Qt 4.x
Call Stack (most recent call first):
CMakeLists.txt:55 (FIND_PACKAGE)
-- Configuring incomplete, errors occurred!
I'm not familiar with CMake and Qt config, but I'm curious what setting force CMake FIND_PACKAGE to look into '/usr/lib/x86_64-linux-gnu/qt4/bin/qmake' for qmake.
I have installed Qt 4.8.5 from source and I have Qt4 bin folder in completely different directory.
just try "sudo apt-get install qt-sdk" it works for me
I solved my problem.
Looking for QT_SELECT with grep command I found that QT_SELECT is related to /usr/lib/x86_64-linux-gnu/qt-default/qtchooser/default.conf file. From the "default" file name I assumed that it is what is seen as QT_SELECT. Other configs presented with qtchooser -l are in /usr/share/qtchooser/ and /usr/lib/x86_64-linux-gnu/qtchooser directories.
Such a config file has two lines with paths. I just changed these lines, first pointing to my Qt bin directory and second pointing to my Qt lib directory. Then I could see that qtchooser -print-env shows QTTOOLDIR and QTLIBDIR to my Qt.
Then I could easily build qjson library with CMake, Qt4 was found correctly.
In my experience, this problem is most easily solved by putting the folder containing qmake in your PATH environment variable.
Here is the answers
https://askubuntu.com/questions/540746/ubuntu-14-04-qt5-development-libraries/540757#540757
Seems
apt-file search Qt5CoreConfig.cmake was what I was missing. This got me:
qtbase5-dev: /usr/lib/x86_64-linux-gnu/cmake/Qt5Core/Qt5CoreConfig.cmake
Installing that seems to lead to CMake finding Qt5. qmake still reports the same problem when directly called though...some remnant from qt4 still installed it seems...
As for the qmake problem, this is fixed by:
sudo apt-get install qt5-default
In my case it was just that qtchooser was missing the "default" configuration.
I figured cmake is just executing qtchooser and looking for a "default" configuration file name.
You can install any configuration file by doing the following:
qtchooser -install <arbitrary_name> <path_to_qmake>
In my case I simply provided "default" as the arbitrary name... this created the default.conf file in the appropriate locations and all is well. I don't think there is a limit to how many named versions of qt you have.
If you do this as root it should work for all users.
On my old RHEL distro, this did it for me:
sudo yum install qt-devel.x86_64
Just the qt-base one wouldn't work with cmake.
1) Where is your qtchooser configuration file?
$: locate qtchooser | grep conf
2) From the list of conf files, probably there is one call "default.conf"
This one is a link to one of the others (4.conf or qt4.conf or 5.conf or qt5.conf).
Choose the one that makes sense too you, and create a link to it.
Suppose your default file path is
/usr/lib/x86_64-linux-gnu/qt-default/qtchooser/default.conf
Create backup:
$: cd $(dirname /usr/lib/x86_64-linux-gnu/qt-default/qtchooser/default.conf)
$: cp -av default.conf default.conf_backup
Let's say you target is
/usr/lib/x86_64-linux-gnu/qtchooser/qt5.conf
Then:
$: sudo ln -s /usr/lib/x86_64-linux-gnu/qtchooser/qt5.conf default.conf
3) Is the path to your qmake right?
Check qmake location
$: locate qmake | grep bin
Is the same one as indicated in your modified qtchooser/default.conf?
$: cat /usr/lib/x86_64-linux-gnu/qtchooser/qt5.conf
If the answer is YES, then you are done.
If the anser is no, then you need to modify the file:
Create backup:
$: cd $(dirname /usr/lib/x86_64-linux-gnu/qtchooser/qt5.conf)
$: cp -av qt5.conf qt5.conf_backup
Edit file and change path to your qmake location
$ sudo vi qt5.conf
Now it should be done.
Simplest solution was add a link in the directory that the gem expected to find it. On Ubuntu 14.04 it qmake lives in /usr/bin. Simple solution.
I have a version of SVN on my system in /usr/bin/svn. This is too old to use with some repositories so I compiled a newer version in /home/user/built/bin/svn which works fine. I added this to my PATH so it should be run first.
Typing
which svn
produces
/home/user/built/bin/svn
however typing
svn --version
reveals that it us using the old version still. if I run
/home/user/built/bin/svn --version
then the correct version is displayed.
Since the custom version is first in my $PATH, and which lists it first why is the older version being invoked when I run svn? I thought which used your $PATH to find executables in the same fashion as the shell?
Use
type svn
to figure out (a) what it is, (b) where it is or what its definition is. Also check that PATH really contains what you think it does
echo $PATH
Type gives:
type svn
svn is hashed (/usr/bin/svn)
Running
hash -r
has now fixed the problem!
Credit to the OP
You sure you don't have a symbolic link to svn somewhere else in your path?
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