[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Pass --build=<triplet> to native builds by default?
From: |
Ludovic Courtès |
Subject: |
Re: Pass --build=<triplet> to native builds by default? |
Date: |
Sun, 04 Jan 2015 21:18:40 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.4 (gnu/linux) |
Mark H Weaver <address@hidden> skribis:
> 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?
[...]
> 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’.