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

[Simon McVittie]

On Sun, 14 Jul 2019 at 08:43:25 +0200, Helmut Grohne wrote:
> Performing a native amd64 build with linux32 sounds seriously broken to
> me.
...
> However, the reverse seems to be somewhat tolerated: Performing a native
> i386 build in an i386 chroot on an amd64 kernel is commonly expected to
> work. In this setting, a linux32 variation makes somewhat sense.

Yes, the policy I would have expected goes something like this:

* packages MUST do a successful non-cross build if $(uname -m) agrees with
  the dpkg host architecture (dpkg says i386 and uname says i[3456]86, etc.)

* packages SHOULD do a successful non-cross build if $(uname -m) indicates
  anything "better than" the baseline for the dpkg architecture (where
  x86_64 > i386, mips64el > mipsel, arm64 > armhf > armel and so on)

* packages are not required to do a successful non-cross build if
  $(uname -m) indicates something "worse than" or incompatible with the
  baseline for the dpkg architecture (e.g. dpkg says amd64 and uname
  says i[3456]86, or dpkg says ppc64 and uname says ppc64el or powerpc)

> As far as I know, the official buildds do linux32 for i386 to avoid
> problems.

Yes. If it was up to me, I would recommend for official/production buildds
(which just want working binaries or a RC bug report) to wrap builds
for all 32-bit architectures in linux32. I think it's OK for QA builds
like reprotest, which want pedantic correctness more than working code,
to try doing 32-bit non-cross builds in a 32-bit chroot on a 64-bit build
machine without linux32, as long as it's understood that the resulting
bug report on failure might not be RC.

> Other than that, my general advice would be preferring $CC -dumpmachine
> over uname -m as it avoids a whole host of problems. Getting there seems
> like a herculean task though.

Is -dumpmachine portable among compilers, or is it a GNU'ism? If it's
specific to gcc, or specific to gcc and compilers like clang that mimic
gcc, or specific to compilers designed with the GNU/Autoconf vocabulary
of CPUs in mind, then I can see why upstreams targeting both GNU and
non-GNU OSs would avoid it.

As far as I can tell, CMake uses uname -m for its vocabulary of Linux CPUs
(but see https://bugs.debian.org/930995), so switching to using the CPU
part of $CC -dumpmachine would be an incompatible change, unless CMake
had a lookup table to map between GNU CPUs and what uname -m would have
said on the relevant machine. I think Meson did this better by having an
explicitly documented table of known CPU names; I would have preferred it
if Meson had reused GNU's vocabulary of CPU names rather than inventing
a new one, but it's too late for that.

Debian::Debhelper::Buildsystem::cmake effectively already does have
a lookup table to map GNU CPUs to uname -m (it's a list of exceptions
rather than a complete table, since in practice they usually match),
but it's currently only used when told to cross-compile, and reprotest's
builds are "officially" not cross-compiling, even if uname -m would
indicate otherwise.

    smcv