[Solved]How can I properly force my Qt Application to loads shared libraries from Certain Directory when it loads?
-
setLibraryPaths() will not solve your problem. That method changes default lib paths for libraries loaded after your application starts (plugins, or stuff loaded with QLibrary).
But Qt libraries (and all other DLLs) are required before the application starts, and are being loaded by your OS. So, that part is handled by the operating system and you have no control over it in your application.
The solution is indeed to use a shell script with LD_LIBRARY_PATH or similar approaches. I know you would rather not do that, but your other possibility in this case is not to distribute your application at all ;)
-
I even tried following shell script and I took out those lines of code
which sets the library path.Then I made following shell script and I checked it that in fact it did not made any changes.
@#!/bin/bash
export LD_LIBRARY_PATH="pwd/Qtlibs"
echo ${LD_LIBRARY_PATH}
ldd ./QtProjectWork $*
@
So still the libraries are downloaded from the opt/Qt/.... directory.
I am wondering if I can set any variable in .pro file to solve the problem.Otherwise I have to compile the code and use it as static library (that I do not know how?).
In fact in Linux Mint/Ubunutu LD_LIBRARY_PATH is not defined !?.
I checked /etc/ld.so.conf.d contents which stores the library paths and I could not find and PATH which points /opt/Qt/5.2.1/..... libraries path that was strange (where the Qt libraries paths are defined ?) and how the system looks for it.
If none of the solution works I have no other alternatives to compile it as static that I have to figure out how :-( -
LD_LIBRARY_PATH is always empty: this is exactly so that you can set it yourself in your scripts :) I definitely use it on Kubuntu and it works. You can also check the bin dir of Qt Creator: they are using the same trick.
If you want to be sure, rename your Qt folder to /opt/Qt-blahblabhblah and then try to run your application with and without the script.
-
"Here":http://www.tripleboot.org/?p=138 you can find great blog about solving this issue from "hskoglund":https://qt-project.org/member/131157 .
-
Thanks qxoz,
I think the chrpath command that I have to use does not need to be installed on the user's machine (please note that user can not install anything) but I can apply on the binaries in advance [I guess the chrpath changed the binary contents and I do not need to change LD_LIBRARY_PATH in script file?] but I can not figure out how can I change the $ORIGIN to something like ./Qtlibs since I want the libraries reside in one directory after the executable not the same directory that the executable is. -
Unfortunately i am more windows user and i am afraid can't give you useful advice :( .
By the way "Qt SDK":https://qt.gitorious.org/qtsdk installer also do something like that. -
Thanks to qxoz and sierdzio I have followed the [tripleboot.com] guidelines
it seems all the problems are solved by using chrpath since it modifies the binaries and change the runtime library path.In fact I have used following command to make it work in linux :
$chrpath -r ./Qtlibs QtProjectWork
it seems that it has modified the binary (checked with md5sum) and the
ldd QtProjectWork could be used as single binary with all the Qt5 libraries installed in [EXEC_PATH]/Qtlibs ---> I got no issues with ldd on missing libraries and the issue is solved. :-) -
Thanks for sharing the solution with us, I have learned something too :)
-
Hi, just saw this thread, great that my blog is helping! I am lazy but I promise more blog posts, like, more on deployment, how to fix Qt's ODBC for Linux/Mac and how to write a QtCreator plugin.
EDIT: forgot, $chrpath -r ./Qtlibs QtProjectWork is a pretty clever idea, makes for less clutter in the app's main directory. And I should mention in the blog, you can indeed do chrpath in advance on your dev. machine.
-
Thanks hskoglund for your great blog.
I would rather to use relative paths instead of absolute due to following reasons:
1 - Different versions of an application on a single machine does not crash when there is a version mismatch between their shared libraries (which only happens if their rpath is not relative path).
2- Access privileges issues for different machines and type of users, user might not get enough privileges to copy and install shared libraries in certain path on the system.
3- Ease and comfort in replacing or upgrading libraries without disturbing other applications that are using the very same shared library, one might imagine the huge differences between libQtCore5.so symbol link if it points to different versions of actual shared libraries such as libQtCore.so.5.0.2 or libQtCore.so.5.2.1 .
