Details
-
Bug
-
Resolution: Done
-
P2: Important
-
1.13.0
-
None
-
KDE Neon on x86_64 host, target custom IMX6 Linux device
-
Linux/X11,
-
386f70fabd7a7741c303c1c58c259adfad6d2ee6 (qbs/qbs/1.13)
Description
A kit set up for cross compiling to ARM imx6 in QtCreator gives these warnings:
:-1: warning: Could not open prl file '<...>/sysroots/armv7at2hf-neon-fslc-linux-gnueabi/opt/qt5.12.3-static/lib/libQt5Bootstrap.prl' for module 'QtBootstrap' (Error: Unable to open file '/<...>/sysroots/armv7at2hf-neon-fslc-linux-gnueabi/opt/qt5.12.3-static/lib/libQt5Bootstrap.prl': No such file or directory), and failed to deduce the library file path. This module will likely not be usable by qbs. :-1: warning: Could not open prl file '<...>/sysroots/armv7at2hf-neon-fslc-linux-gnueabi/opt/qt5.12.3-static/lib/libQt5QmlDevTools.prl' for module 'QtQmlDevTools' (Error: Unable to open file '<...>/sysroots/armv7at2hf-neon-fslc-linux-gnueabi/opt/qt5.12.3-static/lib/libQt5QmlDevTools.prl': No such file or directory), and failed to deduce the library file path. This module will likely not be usable by qbs.
To reproduce, use a Qt install built for cross compiling. In my case, we build Qt statically for use on a ARM IMX6 target device running Linux and EGLFS.
When cross compiling, Qt is installed using 2 prefixes, one for the host tools (such as qmake), the rest are the target libraries to be used on the target device.
libQt5Boostrap and libQt5QmlDevTools (.a, .la and .prl) are installed in <host prefix>/lib, and as far as I know these are not to be used for building binaries for the target platform as they are built for the host platform. Maybe Qbs should just ignore these completely when setting up the Qt profile?