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

[Mark H Weaver]

address@hidden (Ludovic Courtès) writes:

> Mark H Weaver <address@hidden> skribis:
>
>> Mark H Weaver <address@hidden> writes:
>>
>>> address@hidden (Ludovic Courtès) writes:
>>>
>>>> Mark H Weaver <address@hidden> 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?

Using different triplets depending on the architecture revision of the
CPU in the build machine?  I thought we were aiming for deterministic
builds.

I may not have explained the issue clearly.  Please let me try again.

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-*.

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.

      Mark