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
