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

Niels Thykier niels at thykier.net
Sat Sep 14 07:08:00 BST 2019

On Wed, 14 Aug 2019 17:24:00 +0000 Niels Thykier <niels at thykier.net> wrote:
> Control: tags -1 moreinfo

Hi Simon and Helmut,

Is there any update on this?  At the moment, this bug is not actionable
and sprayed over three packages.

(last reply quoted in full so you don't have to look up the bug)


> Simon McVittie:
> > On Sun, 14 Jul 2019 at 08:43:25 +0200, Helmut Grohne wrote:
> >> [...]
> >> 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
> > 
> Hi,
> I am not sure I am any wiser on this bug after reading the bug log other
> than it looks unactionable to me at the moment (hench the moreinfo tag).
> If the conclusion is that debhelper should always pass
> implement that after we confirmed that this is "safe" (doesn't break
> every cmake package in sid, etc.).  However, it is not clear to me
> whether that is the conclusion we reached.
> Thanks,
> ~Niels

More information about the Pkg-cmake-team mailing list