Re: Pass --build=<triplet> to native builds by default?

[ludo@gnu.org (Ludovic Courtès)]

Mark H Weaver <mhw@netris.org> skribis:

> ludo@gnu.org (Ludovic Courtès) writes:
>
>> Mark H Weaver <mhw@netris.org> skribis:
>>
>>> Mark H Weaver <mhw@netris.org> writes:
>>>
>>>> ludo@gnu.org (Ludovic Courtès) writes:
>>>>
>>>>> Mark H Weaver <mhw@netris.org> 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’.