Enrico Zini: Qt cross-architecture development in Debian
Use case: use Debian Stable as an environment to run amd64 development machines
to develop Qt applications for Raspberry Pi or other smallish armhf devices.
Qt Creator is used as Integrated Development Environment, and it supports
cross-compiling, running the built source on the target system, and remote
debugging.
Debian Stable (vanilla or Raspbian) runs on both the host and the target
systems, so libraries can be kept in sync, and both systems have access to a
vast amount of libraries, with security support.
On top of that, armhf libraries can be installed with multiarch also in the
host machine, so cross-builders have access to the exact same libraries as the
target system.
This sounds like a dream system. But. We're not quite there yet.
cross-compile attempts
I tried cross compiling
a few packages:
Some packages work:
With
With
Note: Although I improvised a chroot to be able to fool around with it, I
would use
$ sudo debootstrap stretch cross $ echo "strech_cross" sudo tee cross/etc/debian_chroot $ sudo systemd-nspawn -D cross # dpkg --add-architecture armhf # echo "deb-src http://deb.debian.org/debian stretch main" >> /etc/apt/sources.list # apt update # apt install --no-install-recommends build-essential crossbuild-essential-armhf
# apt source bc
# cd bc-1.06.95/
# apt-get build-dep -a armhf .
# dpkg-buildpackage -aarmhf -j2 -b
dh_auto_configure -- --prefix=/usr --with-readline
./configure --build=x86_64-linux-gnu --prefix=/usr --includedir=\$ prefix /include --mandir=\$ prefix /share/man --infodir=\$ prefix /share/info --sysconfdir=/etc --localstatedir=/var --disable-silent-rules --libdir=\$ prefix /lib/arm-linux-gnueabihf --libexecdir=\$ prefix /lib/arm-linux-gnueabihf --disable-maintainer-mode --disable-dependency-tracking --host=arm-linux-gnueabihf --prefix=/usr --with-readline
dpkg-deb: building package 'dc-dbgsym' in '../dc-dbgsym_1.06.95-9_armhf.deb'.
dpkg-deb: building package 'bc-dbgsym' in '../bc-dbgsym_1.06.95-9_armhf.deb'.
dpkg-deb: building package 'dc' in '../dc_1.06.95-9_armhf.deb'.
dpkg-deb: building package 'bc' in '../bc_1.06.95-9_armhf.deb'.
dpkg-genbuildinfo --build=binary
dpkg-genchanges --build=binary >../bc_1.06.95-9_armhf.changes
dpkg-genchanges: info: binary-only upload (no source code included)
dpkg-source --after-build bc-1.06.95
dpkg-buildpackage: info: binary-only upload (no source included)
qmake based Qt packages, qmake is not configured for cross-building, probably because it is not
currently supported:
# apt source pumpa
# cd pumpa-0.9.3/
# apt-get build-dep -a armhf .
# dpkg-buildpackage -aarmhf -j2 -b
qmake -makefile -nocache "QMAKE_CFLAGS_RELEASE=-g -O2 -fdebug-prefix-map=/root/pumpa-0.9.3=.
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2"
"QMAKE_CFLAGS_DEBUG=-g -O2 -fdebug-prefix-map=/root/pumpa-0.9.3=. -fstack-protector-strong
-Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2"
"QMAKE_CXXFLAGS_RELEASE=-g -O2 -fdebug-prefix-map=/root/pumpa-0.9.3=. -fstack-protector-strong
-Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2"
"QMAKE_CXXFLAGS_DEBUG=-g -O2 -fdebug-prefix-map=/root/pumpa-0.9.3=. -fstack-protector-strong
-Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2"
"QMAKE_LFLAGS_RELEASE=-Wl,-z,relro -Wl,-z,now"
"QMAKE_LFLAGS_DEBUG=-Wl,-z,relro -Wl,-z,now" QMAKE_STRIP=: PREFIX=/usr
qmake: could not exec '/usr/lib/x86_64-linux-gnu/qt5/bin/qmake': No such file or directory
debian/rules:19: recipe for target 'build' failed
make: *** [build] Error 2
dpkg-buildpackage: error: debian/rules build gave error exit status 2
cmake based Qt packages it goes a little better in that it finds the
cross compiler, pkg-config and some multiarch paths, but then it tries to run
armhf moc, which fails:
# apt source caneda
# cd caneda-0.3.0/
# apt-get build-dep -a armhf .
# dpkg-buildpackage -aarmhf -j2 -b
cmake .. -DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_VERBOSE_MAKEFILE=ON -DCMAKE_BUILD_TYPE=None
-DCMAKE_INSTALL_SYSCONFDIR=/etc -DCMAKE_INSTALL_LOCALSTATEDIR=/var -DCMAKE_SYSTEM_NAME=Linux
-DCMAKE_SYSTEM_PROCESSOR=arm -DCMAKE_C_COMPILER=arm-linux-gnueabihf-gcc
-DCMAKE_CXX_COMPILER=arm-linux-gnueabihf-g\+\+
-DPKG_CONFIG_EXECUTABLE=/usr/bin/arm-linux-gnueabihf-pkg-config
-DCMAKE_INSTALL_LIBDIR=lib/arm-linux-gnueabihf
CMake Error at /usr/lib/arm-linux-gnueabihf/cmake/Qt5Core/Qt5CoreConfig.cmake:27 (message):
The imported target "Qt5::Core" references the file
"/usr/lib/arm-linux-gnueabihf/qt5/bin/moc"
but this file does not exist. Possible reasons include:
* The file was deleted, renamed, or moved to another location.
* An install or uninstall procedure did not complete successfully.
* The installation package was faulty and contained
"/usr/lib/arm-linux-gnueabihf/cmake/Qt5Core/Qt5CoreConfigExtras.cmake"
but not all the files it references.
pbuilder or sbuild to do the actual builds.
Helmut suggests pbuilder --host-arch or sbuild --host.
Doing it the non-Debian way
This guide in the meantime explains how
to set up a cross-compiling Qt toolchain in a rather dirty way, by recompiling
Qt pointing it at pieces of the Qt deployed on the Raspberry Pi.
Following that guide, replacing the CROSS_COMPILE value with
/usr/bin/arm-linux-gnueabihf- gave me a working qtbase, for which it is easy
to create a Kit for Qt Creator that works, and supports linking applications
with Debian development packages that do not use Qt.
However, at that point I need to recompile all dependencies that use Qt myself,
and I quickly got stuck at that monster of
QtWebEngine, whose sources embed the whole of
Chromium.
Having a Qt based development environment in which I need to become the
maintainer for the whole Qt toolchain is not a product I can offer to a
customer. Cross compiling qmake based packages on stretch is not currently
supported, so at the moment I had to suggest
to postpone all plans for total world domination for at least two years.
Cross-building Debian
In the meantime, Helmut Grohne has been putting a lot of effort
into making Debian packages cross-buildable:
helmut> enrico: yes, cross building is painful. we have ~26000 source packages. of those, ~13000 build arch-dep packages. of those, ~6000 have cross-satisfiable build-depends. of those, I tried cross building ~2300. of those 1300 cross built. so we are at about 10% working. helmut> enrico: plus there are some 607 source packages affected by some 326 bugs with patches. helmut> enrico: gogo nmu them helmut> enrico: I've filed some 1000 bugs (most of them with patches) now. around 600 are fixed :)He is doing it mostly alone, and I would like people not to be alone when they do a lot of work in Debian, so Join Helmut in the effort of making Debian cross-buildable! Build any Debian package for any device right from the comfort of your own work computer! Have a single development environment seamlessly spanning architecture boundaries, with the power of all that there is in Debian! Join Helmut in the effort of making Debian cross-buildable! Apply here, or join
#debian-bootstrap on OFTC!
Cross-building Qt in Debian
mitya57 summarised the situation on the KDE team side:
mitya57> we have cross-building stuff on our TODO list, but it will likely require a lot of time and neither Lisandro nor I have it currently. mitya57> see https://gobby.debian.org/export/Teams/KDE/qt-cross for a summary of what needs to be done. mitya57> Any help or patches are always welcome :))qemu-user-static Helmut also suggested to use qemu-user-static to make the host system able to run binaries compiled for the target system, so that even if a non-cross-compiling Qt build tries to run
moc and friends in their target
architecture version, they would transparently succeed.
At that point, it would just be a matter of replacing compiler paths to point
to the native cross-compiling gcc, and the build would not be slowed down by
much.
Fixing bug #781226 would help in
making it possible to configure a multiarch version of qmake as the qmake used
for cross compiling.
I have not had a chance of trying to cross-build in this way yet.
In the meantime...
Having qtcreator able to work on an amd64 devel machine and deploy/test/debug
remotely on an arm target machine, where both machine run debian stable and
have libraries in sync, would be a great thing to have even though packages do
not cross-build yet.
Helmut summarised the situation on IRC:
svuorela and others repeat that Qt upstream is not compatible with Debian's multiarch thinking, in that Qt upstream insists on having one toolchain for each pair of architectures, whereas the Debian way tends to be to make packages generic and split stuff such that it can be mixed and matched. An example being that you need to run qmake (thus you need qmake for the build architecture), but qmake also embeds the relevant paths and you need to query it for them (so you need qmake for the host architecture) Either you run it through qemu, or you have a particular cross qmake for your build/host pair, or you fix qt upstream to stop this madnessBuilding qmake in Debian for each host-target pair, even just limited to released architectures, would mean building Qt 100 times, and that's not going to scale. I wonder:
- can I have a
qmake-$ARCHbinary that can build a source using locally installed multiarch Qt libraries, do I need to recompile and ship the whole of Qt, or just qmake? - is there a recipe for building a cross-building Qt environment that would be able use Debian development libraries installed the normal multiarch way?
- we can't do perfect yet, but can we do better than this?
So in the end it was a very successful first week, because I
What happened in the 
There is a strange bug in Planet Debian I am seeing since
I joined. It is rather minor, but since it is an accessibility
bug, I'd like to mention it here. I have written to
the Planet Debian maintainers, and was told to figure it out myself.
This is a pattern, accessibility is considered wishlist, apparently.
And the affected people are supposed to fix it on their own.
It is better if I don't say anything more about that attitude.
