# Cross compiling a Qt application for arm but the target rcc and moc executables are used instead of the host versions

**URL:** https://discourse.cmake.org/t/cross-compiling-a-qt-application-for-arm-but-the-target-rcc-and-moc-executables-are-used-instead-of-the-host-versions/6240
**Category:** Usage
**Created:** [August 11, 2022, 9:26am UTC](https://discourse.cmake.org/t/cross-compiling-a-qt-application-for-arm-but-the-target-rcc-and-moc-executables-are-used-instead-of-the-host-versions/6240 "2022-08-11T09:26:04Z")
**Posts on this page:** 5
**Page:** 1

<div class="post-metadata">

### Author: ![GlennCoombs](https://discourse.cmake.org/user_avatar/discourse.cmake.org/glenncoombs/32/2660_2.png) [@GlennCoombs](https://discourse.cmake.org/u/GlennCoombs)
#### Post date: [August 11, 2022, 9:26am UTC](https://discourse.cmake.org/t/cross-compiling-a-qt-application-for-arm-but-the-target-rcc-and-moc-executables-are-used-instead-of-the-host-versions/6240/1 "2022-08-11T09:26:05Z")

</div>

I am using Debian 10 running on AMD64 and trying to setup a cross compilation environment for an aarch64 target. I have used the following command:

> sbuild-createchroot --debootstrap=qemu-debootstrap --arch=arm64 --chroot-mode=schroot --keep-sbuild-chroot-dir buster /srv/chroots/buster

to create a chroot environment under /srv/chroots/buster which has been populated with aarch64 files. Using schroot I can actually build inside the chroot environment, but because it is using qemu to emulate aarch64 on AMD64 it is painfully slow. I would like to use the native gcc cross compilers to get better speed.

I ran the following cmake command:

> cmake -G “CodeBlocks - Unix Makefiles” -DCMAKE\_TOOLCHAIN\_FILE=/home/glenn/arm64.cmake -DCMAKE\_BUILD\_TYPE=Release …

where the toolchain file looks like this:

> set(CMAKE\_SYSTEM\_NAME Linux)  
> set(CMAKE\_SYSTEM\_PROCESSOR aarch64)  
> set(CMAKE\_SYSTEM\_VERSION 4.14.98-2.3.0+)
> 
> set(CMAKE\_C\_FLAGS “-D\_LARGEFILE\_SOURCE -D\_LARGEFILE64\_SOURCE -D\_FILE\_OFFSET\_BITS=64 -Os ${CMAKE\_C\_FLAGS}” CACHE STRING “Cross compile CFLAGS”)  
> set(CMAKE\_CXX\_FLAGS “-D\_LARGEFILE\_SOURCE -D\_LARGEFILE64\_SOURCE -D\_FILE\_OFFSET\_BITS=64 -Os ${CMAKE\_CXX\_FLAGS}” CACHE STRING “Cross compile CXXFLAGS”)  
> set(CMAKE\_EXE\_LINKER\_FLAGS " ${CMAKE\_EXE\_LINKER\_FLAGS}" CACHE STRING “Cross compile LDFLAGS”)  
> set(CMAKE\_INSTALL\_SO\_NO\_EXE 0)
> 
> set(CMAKE\_PROGRAM\_PATH “/usr/bin”)  
> set(CMAKE\_SYSROOT “/srv/chroots/buster”)  
> set(CMAKE\_FIND\_ROOT\_PATH “/srv/chroots/buster”)  
> set(CMAKE\_FIND\_ROOT\_PATH\_MODE\_PROGRAM NEVER)  
> set(CMAKE\_FIND\_ROOT\_PATH\_MODE\_PACKAGE ONLY)  
> set(CMAKE\_FIND\_ROOT\_PATH\_MODE\_LIBRARY ONLY)  
> set(CMAKE\_FIND\_ROOT\_PATH\_MODE\_INCLUDE ONLY)  
> set(ENV{PKG\_CONFIG\_SYSROOT\_DIR} “/srv/chroots/buster/”)
> 
> set(CMAKE\_C\_COMPILER “/usr/bin/aarch64-linux-gnu-gcc”)  
> set(CMAKE\_CXX\_COMPILER “/usr/bin/aarch64-linux-gnu-g++”)

and I get the following error:

> – The C compiler identification is GNU 8.3.0  
> – The CXX compiler identification is GNU 8.3.0  
> – Check for working C compiler: /usr/bin/aarch64-linux-gnu-gcc  
> – Check for working C compiler: /usr/bin/aarch64-linux-gnu-gcc – works  
> – Detecting C compiler ABI info  
> – Detecting C compiler ABI info - done  
> – Detecting C compile features  
> – Detecting C compile features - done  
> – Check for working CXX compiler: /usr/bin/aarch64-linux-gnu-g++  
> – Check for working CXX compiler: /usr/bin/aarch64-linux-gnu-g++ – works  
> – Detecting CXX compiler ABI info  
> – Detecting CXX compiler ABI info - done  
> – Detecting CXX compile features  
> – Detecting CXX compile features - done  
> – Found Qt version 5.11.3  
> – Configuring done  
> CMake Error: rcc list process failed for:  
> “/home/glenn/liarail/master/PsDemo/PsDemo\_Controller/res.qrc”
> 
> /lib/ld-linux-aarch64.so.1: No such file or directory

The cause of this error seems to be because cmake is trying to run rcc from the schroot environment:

> /srv/chroots/buster/usr/lib/qt5/bin/rcc

instead of using the host version located here:

> /usr/lib/qt5/bin/rcc

If I delete the schroot rcc and replace it with a symbolic link to the host rcc then cmake runs successfuly and generates the Makefiles. I get a similar problem when I try to build but this time it is the moc executable that is wrong. If I use the same symbolic link hack then I can finally get the build to run.

Obviously, my symbolic link hack is not the correct way to solve this problem. I’m not sure if this is a cmake problem or a Qt problem. If it is a cmake problem, is there a cleaner solution than my current ugly hack ? Even if it is a Qt problem, is there a way to work around it in cmake ?

---

<div class="post-metadata">

### Author: ![hsattler](https://discourse.cmake.org/letter_avatar_proxy/v4/letter/h/59ef9b/32.png) [@hsattler](https://discourse.cmake.org/u/hsattler)
#### Post date: [August 11, 2022, 12:02pm UTC](https://discourse.cmake.org/t/cross-compiling-a-qt-application-for-arm-but-the-target-rcc-and-moc-executables-are-used-instead-of-the-host-versions/6240/2 "2022-08-11T12:02:37Z")

</div>

The Qt5 config files do this (see Qt5CoreConfigExtras.cmake). OpenEmbedded has done patches to work around this with the CMake variable OE\_QMAKE\_PATH\_EXTERNAL\_HOST\_BINS. You can achieve similar by predefining the Qt5::qmake, Qt5::moc and Qt5::rcc targets in your toolchain file.

---

<div class="post-metadata">

### Author: ![GlennCoombs](https://discourse.cmake.org/user_avatar/discourse.cmake.org/glenncoombs/32/2660_2.png) [@GlennCoombs](https://discourse.cmake.org/u/GlennCoombs)
#### Post date: [August 12, 2022, 4:23am UTC](https://discourse.cmake.org/t/cross-compiling-a-qt-application-for-arm-but-the-target-rcc-and-moc-executables-are-used-instead-of-the-host-versions/6240/3 "2022-08-12T04:23:34Z")

</div>

Hendrik, thanks for the pointer to the Qt5CoreConfigExtras.cmake file. I have added the following lines to the end of my toolchain file:

```auto
macro(_add_imported_target target_name file)
    if (NOT EXISTS "${file}")
        message(FATAL_ERROR "The imported target \"${target_name}\" references the file \"${file}\" but this file does not exist.")
    endif()

    if (NOT TARGET ${target_name})
        add_executable(${target_name} IMPORTED)
        set_target_properties(${target_name} PROPERTIES IMPORTED_LOCATION ${file})
    endif()
endmacro()

# use the host versions of these executables
_add_imported_target(Qt5::moc "/usr/lib/qt5/bin/moc")
_add_imported_target(Qt5::rcc "/usr/lib/qt5/bin/rcc")
_add_imported_target(Qt5::qmake "/usr/lib/qt5/bin/qmake")

```

and everything now works as expected, even with the target versions of the tools not hacked to be symbolic links pointing to the host versions.

Should there be mention of this somewhere in the cmake documentation on toolchain files and cross compilation ? Or have Qt modified the Qt5CoreConfigExtras.cmake file on the latest release to avoid this problem ?

---

<div class="post-metadata">

### Author: ![cristianadam](https://discourse.cmake.org/user_avatar/discourse.cmake.org/cristianadam/32/124_2.png) [@cristianadam](https://discourse.cmake.org/u/cristianadam)
#### Post date: [August 12, 2022, 2:35pm UTC](https://discourse.cmake.org/t/cross-compiling-a-qt-application-for-arm-but-the-target-rcc-and-moc-executables-are-used-instead-of-the-host-versions/6240/4 "2022-08-12T14:35:57Z")

</div>

You can use `CMAKE_IGNORE_PATH` in your toolchain file to remove some paths that should not be picked by CMake for the `find_program` calls.

You can use `QT_HOST_PATH` to point to the host tools, so that the Qt CMake build system doesn’t try to use the target’s tools.

---

<div class="post-metadata">

### Author: ![cristianadam](https://discourse.cmake.org/user_avatar/discourse.cmake.org/cristianadam/32/124_2.png) [@cristianadam](https://discourse.cmake.org/u/cristianadam)
#### Post date: [August 12, 2022, 2:37pm UTC](https://discourse.cmake.org/t/cross-compiling-a-qt-application-for-arm-but-the-target-rcc-and-moc-executables-are-used-instead-of-the-host-versions/6240/5 "2022-08-12T14:37:10Z")

</div>

Ah, you are trying to build an App and not Qt itself. 🙂
