Details
-
Bug
-
Resolution: Done
-
P3: Somewhat important
-
5.9.3, 5.10.0
-
None
-
Cross-build setup with an {{i386}} host and {{armhf}} target (Raspberry Pi without X11)
* Host: Debian 9.3.0 i386 in a 32-Bit virtual machine (VirtualBox)
* Host's i386 toolchain: apt package {{build-essential}}
* Host's armhf cross-toolchain: apt package {{crossbuild-essential-armhf}}
* Target: Raspbian Stretch Lite 2017-11-29 on a Raspberry Pi 3 (treated as a Pi 2)
Cross-build setup with an {{i386}} host and {{armhf}} target (Raspberry Pi without X11) * Host: Debian 9.3.0 i386 in a 32-Bit virtual machine (VirtualBox) * Host's i386 toolchain: apt package {{build-essential}} * Host's armhf cross-toolchain: apt package {{crossbuild-essential-armhf}} * Target: Raspbian Stretch Lite 2017-11-29 on a Raspberry Pi 3 (treated as a Pi 2)
-
6f242a9389369242b23a61dcb59fc610dc27bb05
Description
Hello,
please see line 151 in qtwebengine/mkspecs/features/gn_generator.prf (source: qt-everywhere-src-5.10.0.tar.xz):
!isEmpty(QT_SYSROOT) {
The QT_SYSROOT property is definitely non-empty in my cross-build setup, yet I noticed that this expression always evaluates to false and that the else-branch of this statement is processed.
Correct me if I'm wrong, but this looks like a syntactical problem because QT_SYSROOT is a qmake property and not a variable (a few lines down in gn_generator.prf it's also properly treated as a property, indicated by the use of the $$[QT_SYSROOT] instead of just $$QT_SYSROOT).
When adding a temporary variable assignment to this expression (this is semantically equal but with comprehensible access to the property's value) it yields true, as it's supposed to in my setup:
QT_SYSROOT_VALUE = $$[QT_SYSROOT] !isEmpty(QT_SYSROOT_VALUE) {
I'm sure there are better ways to go about this, but this modification works as a demonstration as well as a proven fix for my cross-build (tested with Qt 5.9.3 and 5.10.0).
This specific code section of gn_generator.prf generates the values of the preprocessor variables QT_LIBDIR_EGL and QT_LIBDIR_GLES2 in <build>/qtwebengine/src/core/release/BUILD.gn (lines 439-440 in my case, use full-text search to locate them). Without the modification, the variable values are always prefixed with my host's QT_SYSROOT, otherwise not.
These two variable values are later used at run-time (meaning on my cross-build target) in qtwebengine/src/core/surface_factory_qt.cpp (lines 101 and 107) to locate the two shared libraries libEGL.so.1 and libGLESv2.so.2.
So without this modification, my host's QT_SYSROOT prefix ends up in the search path in libQt5WebEngineCore.so.5.10.0 when loading the two shared libraries at run-time on my cross-build target (which of course fails), while with it the QT_SYSROOT prefix is properly removed from that path.
Note that removing the QT_SYSROOT prefix is what gn_generator.prf is actually doing in the true-branch of the expression.
Attachments
Issue Links
- relates to
-
QTBUG-65682 webengine-based applications crash in wayland
-
- Closed
-
-
QTBUG-65749 QtWebEngine searches for libEGL and libGLES in /usr/bin rather than /usr/lib64
-
- Closed
-
For Gerrit Dashboard: QTBUG-65442 | ||||||
---|---|---|---|---|---|---|
# | Subject | Branch | Project | Status | CR | V |
215283,3 | Remove QT_LIBDIR_EGL/GLES2 leftovers | 5.9 | qt/qtwebengine | Status: MERGED | +2 | 0 |