Join GitHub today
Sometimes bundles the wrong Qt #2
When I build an application in Qt Creator, then it has its rpath point to the Qt directory that came with Qt Creator, and that was used for compiling the application.
linuxdeployqt should use that location as the source location when bundling libraries, but it doesn't and bundles Qt from the host system instead, which is guaranteed to break due to version mismatches. Possibly related to #1.
When building an app using Qt Creator, it looks like this:
linuxdeployqt currently wrongly tries to bundle the system Qt from the rpath (
After running linuxdeployqt it looks like this
Which means that the wrong Qt libraries have been copied to the bundle location...
If we find no better solution, we could do like https://github.com/aurelien-rainone/macdeployqtfix and ask the user to provide the "path of Qt libraries used to build the Qt application". However I think this is not elegant and the original macdeployqt doesn't need it.
EDIT: Seems like macdeployqt suffers from the same issue and they are also considering this. https://bugreports.qt.io/browse/QBS-954?focusedCommentId=315655&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-315655
In 4c0da30 it seems to be working... for the moment... if the app can be run from Qt Creator prior to running linuxdeployqt. But sometimes this is not the case, prior to linuxdeployqt I get
Then running linuxdeployqt seems to copy in the wrong Qt libraries from the system.
In which case I can
prior to running linuxdeployqt to make it launch.
When I do that and then run linuxdeployqt, then it seems to copy the correct libraries.
Afterwards when I
then we are up and running!
Tried this with https://github.com/LazyT/obpm
added a commit
Sep 8, 2016
referenced this issue
Sep 22, 2016
To me it seems unreliable to let variables lay the foundation of any sane way of collecting correct path info. Variables can be, and often are, tangled with in very unpredictable maners. On top they are user-space which mean anyone or anything can change them whenever see fit. The most reliable and 'portable' way so far, as I see it, is still the output from
We must not rely on information from from QLibraryInfo:: since it points to the Qt used by the
due to this.
I don't know how to get the path to the correct Qt reliably; it might be necessary for the user to pass it in as an argument.
So we could also do that; check for
Does this logic hold?