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