Building Qt 5.11 Cross on Windows für RPI: Make install fails due to wrong destination path

axeljaeger17

Hello,
I am trying to a cross-build of Qt 5.11 on Windows for a Raspberry Pi. Building Qt works fine but make install fails due to wrong destination paths. The destination path is made up of the sysroot-dir and the prefix but while concatinating both, the configure scripts inserts the drive-letter between sysroot and prefix.

Here is what I tried in detail:

Adopted qmake.conf of the mkspec:

VC_LIBRARY_PATH         = $$[QT_SYSROOT]/opt/vc/lib             # Added $$[QT_SYSROOT] here
VC_INCLUDE_PATH         = $$[QT_SYSROOT]/opt/vc/include         # Also here $$[QT_SYSROOT]

VC_LINK_LINE            = -L$${VC_LIBRARY_PATH}                 # Removed = between -L and [

Issued ./configure with the following commandline

-platform win32-g++ -release -opengl es2 -device linux-rasp-pi3-g++ -sysroot C:/SysGCC/raspberry/arm-linux-gnueabihf/sysroot -prefix /usr/local/qt5 -opensource -confirm-license -device-option "CROSS_COMPILE=arm-linux-gnueabihf-" -nomake examples

After that, I tried issue make install but it fails in the first module, corelib/qtzlib while trying this command:

-$(QINSTALL) C:\qtbuild\qt5112-rpi\qtbase\mkspecs\modules-inst\qt_lib_zlib_private.pri C:$(INSTALL_ROOT:@msyshack@%=%)\SysGCC\raspberry\arm-linux-gnueabihf\sysrootC:\usr\local\qt5\mkspecs\modules\qt_lib_zlib_private.pri

Note the C: in the middle of the destination path between sysroot and \usr\local\qt5....
Manually fixing this path help, however, manually fixing all Makefiles is sheer impractical.

Bonus question: Actually I can use this Qt without installing by adding the appropriate qmake binary in QtCreator.
However, neither qbs nor qmake-based projects are able to find quick components.
I guess this is due to my shadow-build and I am expecting to need a proper install so that both the result of my compilation and the qml-files are copied together into a common directory tree.
Is this a plausible explanation? Will either a non-shadow-build or a developer build solve my problem if there will be no solution to fix the Makefiles?

Best regards,

Axel

koahnig

@axeljaeger17 said in Building Qt 5.11 Cross on Windows für RPI: Make install fails due to wrong destination path:

Hello,
I am trying to a cross-build of Qt 5.11 on Windows for a Raspberry Pi. Building Qt works fine but make install fails due to wrong destination paths. The destination path is made up of the sysroot-dir and the prefix but while concatinating both, the configure scripts inserts the drive-letter between sysroot and prefix.

Here is what I tried in detail:

Adopted qmake.conf of the mkspec:
VC_LIBRARY_PATH         = $$[QT_SYSROOT]/opt/vc/lib             # Added $$[QT_SYSROOT] here
VC_INCLUDE_PATH         = $$[QT_SYSROOT]/opt/vc/include         # Also here $$[QT_SYSROOT]

VC_LINK_LINE            = -L$${VC_LIBRARY_PATH}                 # Removed = between -L and [
Issued ./configure with the following commandline
-platform win32-g++ -release -opengl es2 -device linux-rasp-pi3-g++ -sysroot C:/SysGCC/raspberry/arm-linux-gnueabihf/sysroot -prefix /usr/local/qt5 -opensource -confirm-license -device-option "CROSS_COMPILE=arm-linux-gnueabihf-" -nomake examples
After that, I tried issue make install but it fails in the first module, corelib/qtzlib while trying this command:
-$(QINSTALL) C:\qtbuild\qt5112-rpi\qtbase\mkspecs\modules-inst\qt_lib_zlib_private.pri C:$(INSTALL_ROOT:@msyshack@%=%)\SysGCC\raspberry\arm-linux-gnueabihf\sysrootC:\usr\local\qt5\mkspecs\modules\qt_lib_zlib_private.pri
Note the C: in the middle of the destination path between sysroot and \usr\local\qt5....
Manually fixing this path help, however, manually fixing all Makefiles is sheer impractical.

Probably you need to check on JIRA to check for a bug report or file one.

I am developing on Windows as well, but applications for an embedded device I am cross-compiling on a VM with linux. Out of personal experience is a bit easier then. However, I am copying my application and dynamic libraries rather than using make install. Therefore, I am not sure, if it works even under linux

Bonus question: Actually I can use this Qt without installing by adding the appropriate qmake binary in QtCreator.
However, neither qbs nor qmake-based projects are able to find quick components.
I guess this is due to my shadow-build and I am expecting to need a proper install so that both the result of my compilation and the qml-files are copied together into a common directory tree.
Is this a plausible explanation? Will either a non-shadow-build or a developer build solve my problem if there will be no solution to fix the Makefiles?

Not sure, what you are referring to here?
Apparently you understand that you require cross-compiled for RPi Qt libs. Basically with every set (version) of Qt comes a qmake.exe. This qmake.exe shall be used in conjunction with the Qt libraries it comes with.
In qt creator you are changing the Qt version by basically changing to a different qmake.exe. When you are using qmake.exe of Qt5.4, you are compiling and linking for and with Qt 5.4 and similar it is with other Qt versions.
There might be ways around this association, but all will end in desaster AFAIK.
Therefore IMHO, you shall have a qmake.exe which has been created during the cross-compilation of Qt for RPi. You need to use this qmake.exe

axeljaeger17

I further nailed it down to the file qtbase\bin\qt.conf in the build file tree. Here, the path is already wrong.
Passing -hostprefix -hostprefix C:/SysGCC/raspberry/arm-linux-gnueabihf/sysroot/usr/local/qt5 manually results in Makefiles with working make install targets.

I am aware that I need to use the qmake produced by the cross compile build. I was already using this version of qmake.

I am facing a new problem regarding qtlocation and I will report back as soon as this is resolved. I was also thinking about using a Linux-VM, but because I already had this working on Windows a year ago, I am unwilling to give up yet.

Best regards

Axel

Napi

@axeljaeger17

I am having the same issue. I found a link to a bug ticket QTBUG-6752, look at the last comment from Arvid Brodin. I am going to try it soon.

Let me know if that helps you.