Re: aarch64 electron build failure: fatal error: 'asm/hwcap.h' file not found; mark as BROKEN_aarch64 until fixed?

On Feb 22, 2025, at 23:32, Robert Nagy <rnagy@freebsd.org> wrote:

> On 22/02/25 06:53 -0800, Mark Millard wrote:
>> [Note: I've added rnagy@ for the new www/chromium note.]
>>>>>> QUOTE
>>>>>> archivers/libunrar: Support crc and crypto flags on aarch64
>>>>>> If CPU flags crc or crytpo are set, e.g. -march=armv8-a+crc+crypto, build would fail with missing headers because this was only implemented for glibc and Apple.
>>>>>> END QUOTE
>>>>>> 
>>>>>> I generally have -mcpu=cortex-a76 involved for my aarch64 builds for
>>>>>> the primary machines. That would mean that crc and crypto would be
>>>>>> impicitly enabled.
>> 
>> With archivers/libunrar and devel/electron3[23] fixed for
>> build with crc and/or crypto flags for aarch64, that just
>> leaves www/chromium as failing to build for such contexts.
>> 
>> www/chromium for aarch64 with -mcpu=cortex-a76 also failed
>> with:
>> 
>> In file included from ../../third_party/unrar/src/crypt.cpp:1:
>> In file included from ../../third_party/unrar/src/rar.hpp:6:
>> ../../third_party/unrar/src/os.hpp:167:10: fatal error: 'asm/hwcap.h' file not found
>>  167 | #include <asm/hwcap.h>
>>      |          ^~~~~~~~~~~~~
>> 1 error generated.
>> 
>> which is what the above fixed in libunrar and electron3[23] .
> 
> Hi
> 
> I am inclined to refuse such patches because first I do not see the point.
> Second, chromium is a gigantic project where each component already ammending
> cpu feature flags during the build depending on each subcomponent's needs.
> 
> For e.g.:
> third_party/libyuv will either need +dotprod+i8mm or +sve2 depending on the file.
> Other components will use __attribute__((target("crypto"))) or others.
> 
> Then I will not even talk about runtime issues that will definitely arise with
> custom cpu features.
> 
> The actualy "fix" for this issue is to make the port completely ignore such override
> flags coming from any part of the system (make.conf, environment).

I'll only note that:

} "man 5 make.conf" has documented CPUTYPE since FreeBSD 4.8
  and /usr/share/examples/etc/make.conf has had notes since
  then as well.

) But CPUTYPE gets little coverage elsewhere. While CPUTYPE
  is official and long-term, it is not primary. Not even
  "man 7 tuning" makes reference to it, if I remember right.

From my point of view, CPUTYPE use breaking builds does
seem somewhat odd and that is the current status for aarch64
for a few package builds. (I reference just aarch64 as it is
tier 1. armv7 would have a lesser status, for example.)


Note just for reference:

I'll give a little technical detail for aarch64 for CPUTYPE
handling in /usr/share/mk/bsd.cpu.mk since I originally
referenced -mcpu= notation instead of CPUTYPE:

. elif ${MACHINE_CPUARCH} == "aarch64"
.  if ${CPUTYPE:Marmv*} != ""
# Use -march when the CPU type is an architecture value, e.g. armv8.1-a
_CPUCFLAGS = -march=${CPUTYPE}
.  else
# Otherwise assume we have a CPU type
_CPUCFLAGS = -mcpu=${CPUTYPE}
.  endif

So: -mcpu= usage is normal CPUTYPE handling for aarch64.
(arm has similar logic that would apply for the likes of
cortex-a7 being indicated as an armv7 instance.)

===
Mark Millard
marklmi at yahoo.com