Mark H Weaver <[email protected]> skribis: > [email protected] (Ludovic Courtès) writes: > >> Mark H Weaver <[email protected]> skribis: >> >>> Mark H Weaver <[email protected]> writes: >>> >>>> [email protected] (Ludovic Courtès) writes: >>>> >>>>> Mark H Weaver <[email protected]> skribis: >>>>> >>>>>> It turns out that on ARM systems, the result of 'config.guess' depends >>>>>> on the result of 'uname -m'. In other words, details of the kernel (and >>>>>> perhaps processor?) on the build machine will determine the triplet of >>>>>> our builds, which in turn may affect what set of instructions is used. >>>>> >>>>> Do you know how the ‘uname -m’ output is used in config.guess? What >>>>> does it return on ARM? >>>> >>>> The output of 'uname -m' becomes the first (cpu) component of the GNU >>>> triplet. uname(1) gets its information from the kernel via the uname(2) >>>> system call. The field returned by 'uname -m' is described as "Hardware >>>> identifier". See <http://man7.org/linux/man-pages/man2/uname.2.html>. > > [...] > >>> I forgot to answer your second question. On my Novena, 'uname -m' >>> returns "armv7l". The problem is this: I suspect that if the build >>> machine has an armv8 processor, it will return something different like >>> "armv8l". >> >> But how do the armv7 and armv8 ISAs differ? If it’s more like >> additional SIMD extensions, then indeed it would make sense to use the >> same name for both; but if there’s more than that, perhaps using >> different triplets is the right thing?
[...] > I don't see why it matters how the ISAs differ. The important point is > that a build process may intentionally produce different build outputs > when the triplet is armv8l-* vs armv7l-*. What I meant to say is that “x86_64” is pretty vague and doesn’t specify extensions, but GMP’s sophisticated config.guess is able to determine the available extensions using /proc/cpuinfo and similar tricks. Yet, we’re fine calling all the variants “x86_64” in practice. In fact, it may be that: personality (PER_LINUX32_3GB) on an armv8 machine enters pure armv7 mode. What does “linux32 uname -m” return on armv8? > Even if we didn't care about deterministic builds, there's a more > serious problem. Packages built for armv8l are free to use armv8 ISA > extensions that do not work at all on an armv7l processor. > > As things stand now, we must ensure that none of our build machines > implement ISA extensions beyond the baseline requirements we've chosen > for armhf-linux. OK, understood. Thanks, Ludo’.
