Support relocatable builds of Qt{5,6} #306
Conversation
Also use the environment variable `$QT_ROOT_DIR` probonopd#300 (comment)
kevle
force-pushed
the
qtprefixpath-handling
branch
from
e788c85 to
d1edb3d
Compare
kevle
force-pushed
the
qtprefixpath-handling
branch
from
d1edb3d to
28498fa
Compare
|
Thank you very much @kevle. |
|
Build for testing: |
|
Would be great if someone could test whether this build fixes the issue. Thank you very much! |
| qtPrefixPathRequiresPatch = false | ||
| // Directory should be in ../Qt${qtVersion} | ||
| // TODO: Check if this is true for relocatable binaries in Qt5 | ||
| qt_prfxpath = filepath.Dir(library) + fmt.Sprintf("/../Qt%d", qtVersion) |
There was a problem hiding this comment.
Not this case on Arch Linux.
I have /usr/lib/libQt6Core.so but directory on /usr/lib/qt6. And qt_prfxpath is really empty.
There was a problem hiding this comment.
Note: Before applying this patch, it cannot work on Arch Linux either. So it is not a regression.
There was a problem hiding this comment.
Thanks for testing it, I'll see if I can fix it.
This appears to be the place where the path is configured on Arch:
https://github.com/archlinux/svntogit-packages/blob/5b5e6ab5ccc29af668f41d05ec1fb8e9f8f99595/qt6-base/repos/extra-x86_64/PKGBUILD#L48
|
From the looks of it, there is no way around loading libQtCore{5,6}.so and querying its configuration using QLibraryInfo::location ( Qt5 ) and QLibraryInfo::path ( Qt6 ) to properly handle all cases. This might be possible by using SWIG to generate a wrapper to load I have not been able to find a reliable way to extract this meta information yet ( e.g. from embedded resource files ) any other way. This would be pretty bad news for cross-compilation though, I'm not looking forward to doing qemu shenanigans just to query some paths. |
This PR resolves a problem that leads to corrupted Qt core library files, by detecting relocatable builds of Qt and only conditionally patching the shared library files.
See #302 (comment)