Deploying on linux, executable cannot find shared library at runtime?
-
wrote on 29 Mar 2019, 11:17 last edited by AaronKelsey
I have developed an application that works on Windows and I am working on getting it working on Linux. I have been able to link the libraries during compilation but I am unable to get them to work at runtime.
I have looked everyone on the internet and I have implemented what I believe is the correct approach but unfortunately it does not seem to work no matter what I try.
when running ldd on the binary It shows that it cannot find the libraries despite changing the location for which it should be looking.
linux-vdso.so.1 => (0x00007fff757f5000)
libopensslwrap.so.1 => not found
libQt5Widgets.so.5 => /usr/lib64/libQt5Widgets.so.5 (0x00000038b8e00000)
libQt5Network.so.5 => /usr/lib64/libQt5Network.so.5 (0x00000038b4e00000)
libQt5Xml.so.5 => /usr/lib64/libQt5Xml.so.5 (0x00007f76a89ee000)
libQt5Gui.so.5 => /usr/lib64/libQt5Gui.so.5 (0x00000038b7600000)
libQt5Core.so.5 => /usr/lib64/libQt5Core.so.5 (0x00000038b6e00000)
libicudata.so.52 => not found
libicui18n.so.52 => not found
libicuio.so.52 => not found
libicule.so.52 => not found
libiculx.so.52 => not found
libicutest.so.52 => not found
libicutu.so.52 => not found
libicuuc.so.52 => not found
libcrypto-1_0_2.so.1.0.2 => not found
libssl-1_0_2.so.1.0.2 => not found
libGL.so.1 => /usr/lib64/libGL.so.1 (0x00000038c0200000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00000038b2a00000)
libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00000038bd200000)I have implemented this in my project file but unfortunately It does not do anything.
path/to/project/bin <- where the binary is.
path/to/project/lib <- where the library files are.linux {
QMAKE_LFLAGS_RPATH =
QMAKE_LFLAGS += '-Wl,-rpath,\'\$$ORIGIN/../lib\''
}Can anyone work out what I have done wrong?
-
I have developed an application that works on Windows and I am working on getting it working on Linux. I have been able to link the libraries during compilation but I am unable to get them to work at runtime.
I have looked everyone on the internet and I have implemented what I believe is the correct approach but unfortunately it does not seem to work no matter what I try.
when running ldd on the binary It shows that it cannot find the libraries despite changing the location for which it should be looking.
linux-vdso.so.1 => (0x00007fff757f5000)
libopensslwrap.so.1 => not found
libQt5Widgets.so.5 => /usr/lib64/libQt5Widgets.so.5 (0x00000038b8e00000)
libQt5Network.so.5 => /usr/lib64/libQt5Network.so.5 (0x00000038b4e00000)
libQt5Xml.so.5 => /usr/lib64/libQt5Xml.so.5 (0x00007f76a89ee000)
libQt5Gui.so.5 => /usr/lib64/libQt5Gui.so.5 (0x00000038b7600000)
libQt5Core.so.5 => /usr/lib64/libQt5Core.so.5 (0x00000038b6e00000)
libicudata.so.52 => not found
libicui18n.so.52 => not found
libicuio.so.52 => not found
libicule.so.52 => not found
libiculx.so.52 => not found
libicutest.so.52 => not found
libicutu.so.52 => not found
libicuuc.so.52 => not found
libcrypto-1_0_2.so.1.0.2 => not found
libssl-1_0_2.so.1.0.2 => not found
libGL.so.1 => /usr/lib64/libGL.so.1 (0x00000038c0200000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00000038b2a00000)
libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00000038bd200000)I have implemented this in my project file but unfortunately It does not do anything.
path/to/project/bin <- where the binary is.
path/to/project/lib <- where the library files are.linux {
QMAKE_LFLAGS_RPATH =
QMAKE_LFLAGS += '-Wl,-rpath,\'\$$ORIGIN/../lib\''
}Can anyone work out what I have done wrong?
@AaronKelsey Take a look at https://doc.qt.io/Qt-5/linux-deployment.html
-
Hi,
You can use a qt.conf file to say where the libraries are.
For testing purpose, another way is to set the
LD_LIBRARY_PATH
environment variable to the path where the .libraries can be found. -
wrote on 29 Mar 2019, 21:11 last edited by
Did you tried to use QMAKE_RPATHDIR that doesn't need to explicitly set compiler flags ??
https://doc.qt.io/qt-5/qmake-variable-reference.html#qmake-rpathdirAlso, did you try to run "readelf -d <binary>" to see if the RPATH has been correctly configured into the application binary ??
-
wrote 22 days ago last edited by
You can add the <qtbase>/6.9.1(or other version#)/gcc_64(or other kit compiler name)/lib in your ld.so.conf.d directory for example you we could add
"/usr/share/lib/x86_64-linux-gnu/qt/6.9.1/gcc_64/lib"
(or wherever the libraries (ie, where the libQtLibname* files are)to /etc/ld.so.conf.d/x86_64-linux-gnu.conf
(/!\ Your location and filename may differ a little depending on your platform, pick the one that is for your platform)
Also, don't forget to run "sudo ldconfig" afterwards to ensure that all the needed links are checked and created if needed.As stated above, you can also optionally use LD_LIBRARY_PATH in /etc/environment, but that feels like a misuse of the /etc/environment (though it is useful for setting various QT_ environment variables such as the ones used by Qt applications that determine styles or qt plugins)
Then use ldd afterwards to check if they are resolved (note that there shouldn't be any errors, and only libraries related to ld will not show a linked filename. You can use the -u flag to show unused libraries that the program won't be loading anyway (just be careful of dependencies and be sure you know what libraries your program should be using).
sometimes people get so bored they answer 7 year old questions, those people are nuts, glad I'm not one of those people
-
You can add the <qtbase>/6.9.1(or other version#)/gcc_64(or other kit compiler name)/lib in your ld.so.conf.d directory for example you we could add
"/usr/share/lib/x86_64-linux-gnu/qt/6.9.1/gcc_64/lib"
(or wherever the libraries (ie, where the libQtLibname* files are)to /etc/ld.so.conf.d/x86_64-linux-gnu.conf
(/!\ Your location and filename may differ a little depending on your platform, pick the one that is for your platform)
Also, don't forget to run "sudo ldconfig" afterwards to ensure that all the needed links are checked and created if needed.As stated above, you can also optionally use LD_LIBRARY_PATH in /etc/environment, but that feels like a misuse of the /etc/environment (though it is useful for setting various QT_ environment variables such as the ones used by Qt applications that determine styles or qt plugins)
Then use ldd afterwards to check if they are resolved (note that there shouldn't be any errors, and only libraries related to ld will not show a linked filename. You can use the -u flag to show unused libraries that the program won't be loading anyway (just be careful of dependencies and be sure you know what libraries your program should be using).
sometimes people get so bored they answer 7 year old questions, those people are nuts, glad I'm not one of those people
@osirisgothra hi,
I would say that modifying
ld.so.conf.d
to point to a non system Qt is the wrong way to do that.
Either you have your distribution provided Qt that is installed or you use a wrapper script that will modify LD_LIBRARY_PATH for your application to find the dependencies you provide along said application.