[Pkg-cmake-team] Bug#930997: cmake: reprotest's 'setarch linux32 dh_auto_configure' on amd64 results in CMAKE_SYSTEM_PROCESSOR = i386

[Simon McVittie]

Package: cmake,debhelper,reprotest
Version: 3.13.4-1,12.1.1,0.7.8
Severity: normal

I tried enabling the Salsa CI team pipelines[1] for openjk[2] and
found an unexpected result: in the second of two builds done by
reprotest, openjk is compiled with an x86_64 compiler but appears
to have CMAKE_SYSTEM_PROCESSOR (the equivalent of DEB_HOST_ARCH_CPU)
set to i386. In openjk this results in the loadable modules (which have
architecture-specific names) being named differently, causing extensive
binary differences.

I can't be sure (it isn't currently logged by the salsa-ci-team
pipline[3]) but I think reprotest is using 'setarch i386', equivalent
to linux32(1), for the second build.

I don't know which of the packages involved is at fault here, but this is
surely a problem with at least one of them:

- maybe reprotest shouldn't be using linux32 to build packages for amd64
  when DEB_BUILD_ARCH_CPU and DEB_HOST_ARCH_CPU are both amd64, because
  this causes uname(2) and DEB_BUILD_ARCH_CPU to be inconsistent,
  and causes debhelper's is_cross_compiling() to return false, which
  makes debhelper assume it doesn't need to override things like
  CMAKE_SYSTEM_PROCESSOR?

- or maybe debhelper's cmake build system should be forcing CMake to set
  [CMAKE_HOST_SYSTEM_PROCESSOR to a value appropriate for the
  DEB_BUILD_ARCH_CPU and?] CMAKE_SYSTEM_PROCESSOR to a value appropriate
  for the DEB_HOST_ARCH_CPU even when is_cross_compiling() returns false,
  so that CMake will obey those settings instead of calling uname(2)?

- or maybe it's CMake that should be doing something differently?

A similar situation would presumably appear if you used reprotest on
other 64-bit architectures that have a non-default 32-bit personality,
like aarch64/arm, powerpc64/powerpc and mips64el/mipsel.

Complicating factors:

* CMake cross-compiling terminology is not the same as is used in dpkg,
  so you can't usefully say "host" when discussing this issue without
  clarifying whose definition of host you are using. dpkg uses the GNU
  terminology (as seen in Autotools and Meson), where you compile on the
  build architecture, producing binaries suitable to be run on the host
  architecture (which might themselves in rare cases be cross-compilers
  that produce code for the target architecture). In CMake terminology,
  you compile on the host system (which is the GNU build system),
  producing binaries suitable to be run on the target system (which is
  the GNU host system).

* CMake doesn't document its taxonomy of CPUs (unlike for example dpkg,
  GNU and Meson, which each have a (subtly different!) canonical list),
  and it appears that it will be different on different OSs; but at
  least on Linux (and possibly GNU/kFreeBSD and GNU/Hurd?) it appears
  that in practice it uses (struct utsname).machine, which is the same
  thing as Linux uname -m.

[1] https://salsa.debian.org/salsa-ci-team/pipeline/
[2] https://tracker.debian.org/pkg/openjk
[3] https://salsa.debian.org/salsa-ci-team/pipeline/issues/56