Hi Simon, On Mon, Jun 24, 2019 at 11:28:42AM +0100, Simon McVittie wrote: > - 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?
Performing a native amd64 build with linux32 sounds seriously broken to me. There are very many (non-cmake) packages that rely on uname -m and many of them will misbuild in such a setting. Of course, every such use of uname -m needs to be worked around for cross building. In a perfect world, build systems wouldn't be using uname -m at all. This is not where we are today. 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. A number of build systems (including meson) have code to handle this. As far as I know, the official buildds do linux32 for i386 to avoid problems. So I'd first like to understand the rationale for this reprotest behaviour. 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. Helmut
