hi every one i have installed qwt and include the path
INCLUDEPATH += /usr/local/qwt-6.0.0-rc5/include
LIBS += -L/usr/local/qwt-6.0.0-rc5/lib -lqwt
in my pro file
but when i run my program i get the error
error while loading shared libraries: libqwt.so.6: cannot open shared object file: No such file or directory
/home/cv/abc/abc exited with code 127
even i remove the paths i.e INCLUDE and LIBS and all qwt related thing i am still getting an error am i missing some thing kingly help me
i am using ubuntu 10.04
thanks
In order to execute any program using a shared library, you have to specify where they are.
In your case, you are using shared libraries located at /usr/local/gwt-6.0.0-rc5/lib and you have to tell Linux "ld" that this path is a library path.
To do that, you can include this path at the LD_LIBRARY_PATH environment variable or add it to the /etc/ld.so.conf (or even as a file inside /etc/ld.so.conf.d). After that, ensure you run "ldconfig" make the system aware of this change and try again.
Related
I am using a program called dawg which depends on boost library. I need to run the program on the cluster where I do not have root access. While trying to run the program it returns error as :
/home/masih/Baterial_simulator/dawg_new/my_build/bin/dawg: error while loading shared libraries: libboost_program_options.so.1.65.1: cannot open shared object file: No such file or directory
I installed the boost 1.65.1 package manually and have put it in the '.bashrc' file as following:
#export LD_LIBRARY_PATH="/home/masih/Baterial_simulator/boost_1_65_1/lib/lib:$LD_LIBRARY_PATH"
the file ' libboost_program_options.so.1.65.1' exist in the ' /home/masih/Baterial_simulator/boost_1_65_1/lib/lib ' but still I get the error.
I have also tried to include the boost package information while configuring the package by putting the following lines in the 'CMakeLists.txt'
SET (BOOST_ROOT "/home/masih/Baterial_simulator/boost_1_65_1/lib")
SET (BOOST_INCLUDEDIR "/home/masih/Baterial_simulator/boost_1_65_1/lib/include")
SET (BOOST_LIBRARYDIR "/home/masih/Baterial_simulator/boost_1_65_1/lib/lib")
The installation completes without any error but trying to run the program returns the same error again.
The cluster is using RedHat OS.
Give the path of directory where your program is running.
For Example:
Below line will direct library-path to your current/program directory.
if already set then use : unset LD_LIBRARY_PATH
export LD_LIBRARY_PATH=/home/masih/Baterial_simulator/dawg_new/my_build/bin/dawg:$LD_LIBRARY_PATH
Note: This command only work when libboost_program_options.so.1.65.1 is installed in system lib path.
If not working then direct your library path to path of your running program.
export LD_LIBRARY_PATH=/home/masih/Baterial_simulator/boost_1_65_1/lib/lib:/home/masih/Baterial_simulator/dawg_new/my_build/bin/dawg
I tried to run a program that requires log4cpp,
I got following error when I try to run the program
error while loading shared libraries: liblog4cpp.so.4: cannot open shared object file: No such file or directory
I have set the library path in $LD_LIBRARY_PATH and these are the files in my /usr/local/lib directory:
liblog4cpp.a
liblog4cpp.so
liblog4cpp.so.5.0.6
liblog4cpp.la
liblog4cpp.so.5
pkgconfig
What could be the problem here ?
Thanks!
Use
ldd [program name]
so see what's actually loaded (assuming you are on a Unix system since you use LD_LIBRARY_PATH).
I am trying to write a simple application with GLFW on Linux. Right now the main file (the only file) is basically just a few lines of code to make sure the dynamic library linked correctly. Here it is:
#include <GLFW/glfw3.h>
#include <iostream>
int main()
{
glfwInit();
std::cout << "It works this far!" << std::endl;
glfwTerminate();
}
The include files are stored in a directory labelled "include" and the library files are stored in a directory labelled "lib". As of right now, I am compiling the program with the following line:
g++ -Wl,-Rlib -Iinclude -Llib test.cpp -o test -lglfw.3.2
It compiles and links just fine, but when I try to execute it, I get the following error:
./test: error while loading shared libraries: libglfw.so.3: cannot open shared object file: No such file or directory
Now, before you rush to downvote this question into oblivion and mark it as a duplicate, at least allow me to explain why I believe my question is different enough to not be a duplicate. I already attempted the solutions that the other questions presented, but it was unsuccessful. As you can see, I tried setting the path to the library during linking with the -Wl,-Rlib tag. I also tried setting LD_LIBRARY_PATH to point to the location of my libraries (the 'lib' folder), but it still threw the same error. (It didn't matter if the path was relative or absolute.)
So, the next thing I tried was running the ldd command on the executable. I got some other dependencies that were working just fine, but importantly, I got this:
libglfw.so.3 => not found
For some reason, it insists on looking for libglfw.so.3. It will not have it any other way. Upon renaming the library from libglfw.3.2.so to libglfw.so.3, the program executed just fine and printed It works this far! as if there were no problems at all.
Why would this happen?
For some reason, it insists on looking for libglfw.so.3. ... Upon renaming the library from libglfw.3.2.so to libglfw.so.3 ...
The ELF executables contain the exact name of the dynamic libraries used.
If the executable contains the library name "libglfw.so.3" the file must be named exactly like this.
The file naming scheme is intentionally done in a way that not the "full" version is coded into the file name: This way a later version ("libglfw.so.3.15") will work with the executable.
Normally there should be a symbolic link to the latest version of the library installed:
libglfw.so.3 -> libglfw.so.3.2
This symbolic link seems to be missing on your computer. I would say that this is an installation problem!
EDIT
The question could be: Why is the file name stored in the executable file not libglfw.3.2.so but libglfw.so.3?
The answer has to do with the backward compatibility when a new version of a library is installed:
Normally you would use the switch -lglfw and a symbolic link named libglfw.so is looked up.
If you stored the file name libglfw.so in the executable file and a new, incompatible version if this library (libglfw.so.4) is installed you would have no chance to get the program running by having both versions of the library installed.
To enable backward compatibility by having both versions of the library installed the "real" symbolic link name of the library (libglfw.so.3) must be stored in the executable file.
Therefore the "expected" file name of a library is stored in the library itself: Inside the file libglfw.so.3.2 you'll find some information that the file expects itself to be stored as libglfw.so.3.
The linker will use this information about the file name because it assumes that the library name given in the linker switch (-lglfw) is less "precise" than the name stored in the library itself.
For some reason, it insists on looking for libglfw.so.3. It will not have it any other way.
This is the Linux convention for shared libraries which is described here among other places. For Linux libfoo.so.x.y.z is considered to have the same ABI as libfoo.so.x. Usually when shared libraries are installed (e.g. via rpm, dpkg, etc.) there's an invocation of ldconfig that happens so that the just installed libraries have a symlink following the convention installed that references the library. Also these libs (if installed to a "trusted location"), are added to a linker cache for performance reasons.
It compiles and links just fine, but when I try to execute it, I get the following error:
./test: error while loading shared libraries: libglfw.so.3: cannot open shared object file: No such file or directory
libglfw.so.3 isn't on ld-linux.so's path.
As you can see, I tried setting the path to the library during linking with the -Wl,-Rlib
Still won't find it -- libglfw.so.3 isn't on ld-linux.so's path. You can add it by doing something like:
ldconfig -n /path/to/lib
Which should output the requisite libglfw.so.3 symlink for your lib.
IIRC setting the rpath might require a full path.
I also tried setting LD_LIBRARY_PATH to point to the location of my libraries
Again, libglfw.so.3 isn't on ld-linux.so's path.
last week I recieved my brand new Colibri VF61 with the Aster carrier board from Toradex.
I followed Toradex's guide on how to prepare the board to cross compile with qt here.
Everything from the tuturial went perfect, however I tried deploying my app and everything goes fine until I open the executable on my target device because I get the following message :
error while loading shared libraries: libQt5PrintSupport.so.5: cannot open shared object file: No such file or directory
I went to see if I had any Qt files in my target device at all, and there weren't so I went to my sysroot folder in my host device and I copied all the Qt files to my target device, (Qt5PrintSupport was there) but after I copied all the files in the exact same location as they where in my sysroot the same error keep appearing.
The files I copied were:
LibIcal Qt5Core Qt5OpenGLExtensions Qt5Svg
PulseAudio Qt5DBus Qt5Positioning Qt5SystemInfo
Qt5 Qt5Declarative Qt5PrintSupport Qt5Test
Qt53DCore Qt5Designer Qt5PublishSubscribe Qt5UiPlugin
Qt53DExtras Qt5Enginio Qt5Qml Qt5UiTools
Qt53DInput Qt5Gui Qt5Quick Qt5WebChannel
Qt53DLogic Qt5Help Qt5QuickTest Qt5WebKit
Qt53DQuick Qt5LinguistTools Qt5QuickWidgets Qt5WebKitWidgets
Qt53DQuickExtras Qt5Location Qt5Script Qt5WebSockets
Qt53DQuickInput Qt5Multimedia Qt5ScriptTools Qt5Widgets
Qt53DQuickRender Qt5MultimediaWidgets Qt5Sensors Qt5X11Extras
Qt53DRender Qt5Network Qt5SerialPort Qt5Xml
Qt5Bluetooth Qt5Nfc Qt5ServiceFramework Qt5XmlPatterns
Qt5Concurrent Qt5OpenGL Qt5Sql libxml2
Inside /usr/lib/cmake
and:
imports libexec mkspecs plugins qml
folders to /usr/lib/qt5
I have noticed that the problem may be that I dont have the "lib" folder inside /usr/lib/qt5 however I don't know how to create it since it wasn't in my sysroot.
Summing up: I want to execute my app by cross compiling but the lib folder is missing and I don't know how to create it or link it.
Having a library in the same path with the app using it doesn't necessarily mean that your app can find it. Follow one of the methods below;
Install the required qt libraries into system's standard lib directory(e.g. /usr/lib/)
Set environment variable LD_LIBRARY_PATH to where your qt libraries exist. Convention is generally having a bash script setting it then launching your app) or
At compile time, you set rpath variable to the location of qt libraries folder (-rpath for gcc)
I'm having trouble finding why this library (matio) isn't working for me. In my Makefile I have this:
LIBS += -L/home/brian/.../matio-1.5.6/src/.libs/ -lmatio
When I attempt to run my code (links fine) I get this error:
error while loading shared libraries: libmatio.so.4: cannot open shared object file: No such file or directory
libmatio.so.4 exists in the directory specified by the -L flag.
I built the library and it seems to go through make check with only a handful writing errors (which is fine as I only need it for reading).
Things I've tried:
Specifying the name (i.e. -l:libmatio.so.4.0.2)
Adding the path to LD_LIBRARY_PATH
Adding the path as a line in /etc/ld.so.conf and run sudo ldconfig
Adding a new file in /etc/ld.so.conf.d with the path and run sudo ldconfig
(When I run ldconfig -p | grep matio nothing returns. Am I doing something wrong with ldconfig?)
The error is actually telling you "no compatible library with that name exists in the library cache", not "no file with that filename exists on disk".
So, confusingly, this can happen when the shared object file is in the wrong format.
Ensure that it was built for the right platform by the right compiler! You can have a look with file and verify that the dynamic link is failing using ldd on your executable.