On Feb 22, 2025, at 23:32, Robert Nagy <rn...@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
