Cross-compile toolchain error with Qtt5 on Raspberry Pi

[NickD2039]

Hi,

I installed the corresponding Raspbian image and toolchain as per your instructions (2019-07-10-raspbian-buster-full and raspberry-gcc8.3.0.exe) and installed the OS on the pi.

As a first step, I created an MSBuild C++ project and succesfully cross-compiled and remote debugged it on the Pi.

I then installed Qt5 on the Pi as follows:

sudo apt-get update
sudo apt-get install qt5-default

I then created a new Qt based cross-compile project with VisualGDB and set the template to ‘A Qt5-based application’. Click finish and I’m told that the Qt headers need to be synchronized, so I do. There are a few failures reported in the issues window:

Unreadable symbolic link 'usr/lib/jvm/java-11-openjdk-armhf/lib/src.zip', error code 2
Unreadable symbolic link 'usr/lib/debug/usr/lib/jvm/java-1.11.0-openjdk-armhf', error code 2
Unreadable symbolic link 'usr/lib/nodejs/form-data/index.js', error code 2
Unreadable remote directory 'usr/lib/ssl/private', error code 13
Failed to read file 'usr/lib/cups/backend/vnc', error code 13
Failed to create symlink '\\?\c:\sysgcc\raspberry\arm-linux-gnueabihf\sysroot\usr\include\python2.7\numpy', error code 145
Failed to create symlink '\\?\c:\sysgcc\raspberry\arm-linux-gnueabihf\sysroot\usr\include\python3.7m\numpy', error code 145
Failed to create symlink '\\?\c:\sysgcc\raspberry\arm-linux-gnueabihf\sysroot\usr\include\python3.7', error code 145
Failed to create symlink '\\?\c:\sysgcc\raspberry\arm-linux-gnueabihf\sysroot\usr\include\numpy', error code 145
Failed to create symlink '\\?\c:\sysgcc\raspberry\arm-linux-gnueabihf\sysroot\usr\include\libpng', error code 145
Failed to create symlink '\\?\c:\sysgcc\raspberry\arm-linux-gnueabihf\sysroot\usr\lib\gcc\arm-linux-gnueabihf\6.5.0', error code 145
Failed to create symlink '\\?\c:\sysgcc\raspberry\arm-linux-gnueabihf\sysroot\usr\lib\arm-linux-gnueabihf\perl\5.28', error code 145

I ignore those errors and continue, and it fails at the ‘Preparing build subsystem..’ step of testig the toolchain. An error window pops up that says:

Toolchain Test Failed
VisualGDB has attempted to test your settings by building a simple project and encountered the following error:
Failed building temporary makefile

Detailed log:

Tool arguments: C:\SysGCC\raspberry\Qt\v5\qmake.exe TestProFile.pro CONFIGNAME=Debug
C:/SysGCC/raspberry/arm-linux-gnueabihf/sysroot/usr/lib/arm-linux-gnueabihf/qt5/mkspecs/features/toolchain.prf:69: system(execute) requires one or two arguments.
Project ERROR: Cannot run compiler 'C:/SysGCC/raspberry/bin/arm-linux-gnueabihf-g++.exe'. Output:
===================
===================
Maybe you forgot to setup the environment?

I hit Ignore and it says ‘Please verify the consistency of your toolchain’

Attempting to build the project anyway also fails with the same error, from Build output:

1>------ Build started: Project: LinuxProject6, Configuration: Debug Win32 ------
1>Updating C:\project\other\LinuxProject6\LinuxProject6\LinuxProject6.pro
1>VisualGDB: Updated source file list in C:\project\other\LinuxProject6\LinuxProject6\LinuxProject6.pro. Enable verbose mode for more details.
1>VisualGDB: Run "C:\SysGCC\raspberry\Qt\v5\qmake.exe LinuxProject6.pro CONFIGNAME=Debug" in directory "C:\project\other\LinuxProject6\LinuxProject6" on local computer
1>C:/SysGCC/raspberry/arm-linux-gnueabihf/sysroot/usr/lib/arm-linux-gnueabihf/qt5/mkspecs/features/toolchain.prf:69: system(execute) requires one or two arguments.
1>EXEC : Project error : Cannot run compiler 'C:/SysGCC/raspberry/bin/arm-linux-gnueabihf-g++.exe'. Output:
1>===================
1>===================
1>Maybe you forgot to setup the environment?
1>-------------------------------------------------------------
1>Command exited with code 3
1>Executable: C:\SysGCC\raspberry\Qt\v5\qmake.exe
1>Arguments: LinuxProject6.pro CONFIGNAME=Debug
1>Directory: C:\project\other\LinuxProject6\LinuxProject6
1>VisualGDB : error : Command-line action failed
1>VisualGDB : error : Build has failed. See the Output window for more details.
1>C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\Common7\IDE\VC\VCTargets\Microsoft.MakeFile.Targets(44,5): error MSB3073: The command ""C:\Program Files (x86)\Sysprogs\VisualGDB\\VisualGDB.exe" /build "C:\project\other\LinuxProject6\LinuxProject6\LinuxProject6.vcxproj" "/solution:C:\project\other\LinuxProject6\LinuxProject6.sln" "/config:Debug" "/platform:Win32"" exited with code 1.
1>Done building project "LinuxProject6.vcxproj" -- FAILED.
========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========

The toolchain is not compromised because after this I created another non-Qt (MSBuild) app and it cross-compiles and deploys/runs successfully, so it’s something particular to cross-compiling Qt apps.

The Qt version that apt-get retrieved is 5.11.3 and VisualGDB is installed on VisualStudio 2017.

Thanks in advance,

Nick

• This topic was modified 5 years, 5 months ago by NickD2039.

[NickD2039]

I think the problem is due to the version of the Qt tools that were downloaded by VisualGDB when I setup the Qt project.

Running \SysGCC\raspberry\Qt\v5\qmake.exe -v results in:

QMake version 3.0
Using Qt version 5.4.0 in c:/sysgcc/raspberry/arm-linux-gnueabihf/sysroot/usr/lib/arm-linux-gnueabihf

Which is very old. I tried bypassing it by manually calling qmake from a windows installation of Qt and the next compile attempt complained that ‘take_first' is not a recognized replace function.‘ And a google of that yielded a result in https://forum.qt.io/topic/93633/qmake_use-prf-6-take-first-is-not-a-recognized-replace-function/14

Where one commenter said ‘take_first() is part of the qmake language since Qt 5.8.0‘ so the toolchain.prf is incompatible with the qt tools that VisualGDB downloaded.

How can I reconfigure VisualGDB to use a specific version of the Qt tools?

[NickD2039]

UPDATE: I installed Qt 5.11.3 MinGW and tried to use the tools from that: Configure Qt Settings, Use qmake.exe etc. from a MinGW build of Qt, entered the qmake location (in my case C:\Qt\Qt5.11.3\5.11.3\mingw53_32\bin) hit Ok and then Finish. Same error occurs as it still uses the qmake from the cross-compile toolchain instead of the one I selected. If I re-open the Configure Qt Settings dialog I see that it has changed to ‘Use previously configured Qt tools for cross-compilation’. I can change it back but it always reverts to that when I hit Finish.

Would really like to find a solution to this as otherwise I’m super-impressed by VisualGDB and would love to use it 😉

Remote complation is not an option due to the size of the project that I’m attempting to port.

TIA

[support]

Hi,

Sorry, the latest Raspberry Pi toolchain is not compatible with QMake anymore. Please try using VisualGDB 5.5 Preview 1 and create a CMake-based Qt project as shown here: https://visualgdb.com/tutorials/linux/qt/cmake/. This should work out-of-the-box.

[NickD2039]

Hi Support,

Unfortunately the objective is to port a large qmake-based project to the Pi and it has a complicated qmake pro-file structure that would be very impractical to port to cmake.

Is there another workaround for this? I’m prepared to compile Qt (at least the tools) from source but would need guidance on doing this.

It’s a shame as VisualGDB looks very promising and I would definitely spring for a licence after a successful evaluation.

Thanks,

Nick

[support]

Hi,

Yes, please try using the older toolchain based on the Raspbian Stretch distribution (you would also need the older SD card image). It is compatible with QMake and will work out-of-the-box.

Unfortunately, we are not able to provide guidance on porting a 3rd-party framework to an unsupported 3rd-party platform as a part of our regular product support, however we might be able to create a port for you as a part of our paid consulting services. Please feel free to reach out to our sales if you would like a quote.

[NickD2039]

Hi,

Thanks for the swift reply.

What’s the timeframe for addressing the issue with QMake in VisualGDB?

Thanks,

Nick

 

• This reply was modified 5 years, 5 months ago by NickD2039.
• This reply was modified 5 years, 5 months ago by NickD2039.

[support]

Hi,

Generally, we are not able to resolve compatibility issues between 3rd-party components as a part of VisualGDB. However, we are happy to support the tool/platform combinations that do work reliably and provide convenient interface for developing projects for those configurations.

If you would like to get a time/cost estimate on customizing 3rd-party products beyond the supported configurations, please contact our sales, as the estimates are made on a case-by-case basis.

• This reply was modified 5 years, 5 months ago by support.

[NickD2039]

Hi,

I think you may have misunderstood: I meant what is the timeframe for fixing the bug with VisualGDB where it downloads an out-of-date qmake? Or are you dropping support for qmake altogether? (which would be a deal-breaker for me).

Also, are you saying that Raspberry Pi is an unsupported platform as far as VisualGDB is concerned?

Nick

• This reply was modified 5 years, 5 months ago by NickD2039.

[support]

According to our best knowledge, there is no version of QMake that will work with the latest Raspberry Pi cross-toolchain. If such a version is ever released, we should be able to integrate it into VisualGDB promptly.

VisualGDB still supports QMake, as long as it is compatible with your toolchain/target combination. We do not release any special versions of QMake and do not control its compatibility with various platforms and targets.

[NickD2039]

The problem is that the version of qmake that VisualGDB downloads is very old (Qt 5.4.x) which is why it doesn’t work. A later version of qmake (say 5.11.3) would definitely work with that toolchain. Where does VisualGDB download the Qt tools from?

[support]

Unfortunately, the internal structure of the latest QMake has changed in a way that does not allow VisualGDB to patch it to work with the Raspberry Pi cross-toolchain.

Simply replacing the QMake executable with a newer version will not work (you can verify this by downloading QMake from any other Qt package). As Qt is now fully compatible with CMake without any special patching, we recommend using CMake for all new targets that are not compatible with the old QMake that could be easily patched.

[Author]

Posts