Towards convenient cross compiling with CMake


Today some new features were merged to CMake master to interface with some
Clang features.

CMAKE_<LANG>_COMPILER_EXTERNAL_TOOLCHAIN — CMake 3.24.20220824-g95dd428 Documentation

CMAKE_SYSROOT — CMake 3.24.20220824-g95dd428 Documentation;a=commitdiff;h=76552d59;a=commitdiff;h=5096967e;a=commitdiff;h=7cd65c97

This simplifies the toolchain to something like this:


  set(CMAKE_SYSROOT /home/stephen/rpi/rasp-pi-rootfs)
  set(CMAKE_FIND_ROOT_PATH /home/stephen/dev/src/qtbase-rpi/extprefix)
  set(gcc_toolchain /home/stephen/rpi/gcc-4.7-linaro-rpi-gnueabihf)

  set(triple arm-linux-gnueabihf)

  set(CMAKE_C_COMPILER /usr/bin/clang)
  set(CMAKE_C_COMPILER_TARGET ${triple})
  set(CMAKE_CXX_COMPILER /usr/bin/clang++)

  # Debian bug 708744
  include_directories(SYSTEM "${CMAKE_SYSROOT}/usr/include/${triple}")


As an alternative to specifying the -target, CMake master also knows how to
use symlinked ${triple}-clang executables.

Find appropriate binutils when cross-compiling with clang (b84f5c2e) · Commits · CMake / CMake · GitLab

The commit at

will be merged when Clang 3.4 is released.

I have not been able to make cross-compiling work with my ubuntu supplied
clang, nor with the version at (various issues related
to binutils which I've posted to the list about before). It works with my
self-build of trunk though. The Debian clang maintainer told me on IRC that
cross-compiling is not a target use-case for his packages. If the packages also use his patches, that would explain it.

I would appreciate if you try it out with your cross-compiling setups and
give feedback about how well it works. I am also interested in what your
toolchain file looks like generally, and what else could/should be
abstracted by CMake generally, or with user configuration in the toolchain