Date: Sat, 31 Aug 2024 13:39:36 -0700 From: Mark Millard <marklmi@yahoo.com> To: "mmel@freebsd.org" <mmel@FreeBSD.org> Cc: FreeBSD Mailing List <freebsd-ports@freebsd.org>, FreeBSD ARM List <freebsd-arm@freebsd.org>, FreeBSD Toolchain <freebsd-toolchain@freebsd.org>, Brooks Davis <brooks@FreeBSD.org>, Tomoaki AOKI <junchoon@dec.sakura.ne.jp> Subject: Re: For an armv7 context, /usr/local/llvm1[789]/lib/clang/1[789]/include/arm_bf16.h does not exist: one thing blocking a firefox build via llvm1[78] Message-ID: <03DB526D-6B4B-42DF-B5E2-609E174A8311@yahoo.com> In-Reply-To: <E2BE2A87-D067-4FFB-B649-F5BE0C2D0CD2@yahoo.com> References: <75609A57-7B50-40F5-88A8-0278CCCC018B@yahoo.com> <E029410D-1964-4C55-8B2D-0427C43B4ABA@yahoo.com> <D74514BA-9071-4F29-96F5-42AD6EC2B6E4@yahoo.com> <DF65D496-D1E7-44B6-A04F-EADA1DE29817@yahoo.com> <24D56998-0939-43D0-A98C-E398CCDA0AAA@yahoo.com> <71a16edd-94e7-4a06-9a34-59f17c442a96@FreeBSD.org> <E2BE2A87-D067-4FFB-B649-F5BE0C2D0CD2@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Aug 31, 2024, at 10:43, Mark Millard <marklmi@yahoo.com> wrote:
> On Aug 31, 2024, at 00:16, Michal Meloun <mmel@freebsd.org> wrote:
>=20
>> On 31.08.2024 8:29, Mark Millard wrote:
>>> On Aug 30, 2024, at 22:05, Mark Millard <marklmi@yahoo.com> wrote:
>>>> On Aug 30, 2024, at 21:26, Mark Millard <marklmi@yahoo.com> wrote:
>>>>=20
>>>>> On Aug 30, 2024, at 20:33, Mark Millard <marklmi@yahoo.com> wrote:
>>>>>=20
>>>>>> [Subject was retitled.]
>>>>>>=20
>>>>>> On Aug 30, 2024, at 16:24, Mark Millard <marklmi@yahoo.com> =
wrote:
>>>>>>=20
>>>>>>> What my test-of-building got was: No <arm_bf16.h> include file =
found and
>>>>>>> no OFlags::TMPFILE found (OFlags:: was found, TMPFILE in =
OFlags:: was not):
>>>>>>>=20
>>>>>>> In file included from =
/wrkdirs/usr/ports/www/firefox/work/firefox-129.0.2/mfbt/lz4/xxhash.c:43:
>>>>>>> In file included from =
/wrkdirs/usr/ports/www/firefox/work/firefox-129.0.2/mfbt/lz4/xxhash.h:3434=
:
>>>>>>> /usr/local/llvm17/lib/clang/17/include/arm_neon.h:37:10: fatal =
error: 'arm_bf16.h' file not found
>>>>>>> 37 | #include <arm_bf16.h>
>>>>>>> | ^~~~~~~~~~~~
>>>>>>> . . .
>>>>>>>=20
>>>>>>> error[E0599]: no associated item named `TMPFILE` found for =
struct `backend::fs::types::OFlags` in the current scope
>>>>>>> --> =
/wrkdirs/usr/ports/www/firefox/work/firefox-129.0.2/third_party/rust/rusti=
x/src/backend/libc/fs/syscalls.rs:144:32
>>>>>>> |
>>>>>>> 144 | if oflags.contains(OFlags::TMPFILE) && =
crate::backend::if_glibc_is_less_than_2_25() {
>>>>>>> | ^^^^^^^ associated item not =
found in `OFlags`
>>>>>>> |
>>>>>>> ::: =
/wrkdirs/usr/ports/www/firefox/work/firefox-129.0.2/third_party/rust/rusti=
x/src/backend/libc/fs/types.rs:203:1
>>>>>>> |
>>>>>>> 203 | / bitflags! {
>>>>>>> 204 | | /// `O_*` constants for use with [`openat`].
>>>>>>> 205 | | ///
>>>>>>> 206 | | /// [`openat`]: crate::fs::openat
>>>>>>> ... |
>>>>>>> 333 | | }
>>>>>>> 334 | | }
>>>>>>> | |_- associated item `TMPFILE` not found for this struct
>>>>>>> |
>>>>>>> . . .
>>>>>>> =3D note: this error originates in the macro =
`$crate::__impl_bitflags` which comes from the expansion of the macro =
`bitflags` (in Nightly builds, run with -Z macro-backtrace for more =
info)
>>>>>>>=20
>>>>>>> . . .
>>>>>>>=20
>>>>>>> error[E0599]: no associated item named `TMPFILE` found for =
struct `backend::fs::types::OFlags` in the current scope
>>>>>>> --> =
/wrkdirs/usr/ports/www/firefox/work/firefox-129.0.2/third_party/rust/rusti=
x/src/backend/libc/fs/syscalls.rs:207:32
>>>>>>> |
>>>>>>> 207 | if oflags.contains(OFlags::TMPFILE) && =
crate::backend::if_glibc_is_less_than_2_25() {
>>>>>>> | ^^^^^^^ associated item not =
found in `OFlags`
>>>>>>> |
>>>>>>> ::: =
/wrkdirs/usr/ports/www/firefox/work/firefox-129.0.2/third_party/rust/rusti=
x/src/backend/libc/fs/types.rs:203:1
>>>>>>> |
>>>>>>> 203 | / bitflags! {
>>>>>>> 204 | | /// `O_*` constants for use with [`openat`].
>>>>>>> 205 | | ///
>>>>>>> 206 | | /// [`openat`]: crate::fs::openat
>>>>>>> ... |
>>>>>>> 333 | | }
>>>>>>> 334 | | }
>>>>>>> | |_- associated item `TMPFILE` not found for this struct
>>>>>>> |
>>>>>>> . . .
>>>>>>> =3D note: this error originates in the macro =
`$crate::__impl_bitflags` which comes from the expansion of the macro =
`bitflags` (in Nightly builds, run with -Z macro-backtrace for more =
info)
>>>>>>>=20
>>>>>>> . . .
>>>>>>> =3D note: this error originates in the macro =
`$crate::__impl_bitflags` which comes from the expansion of the macro =
`bitflags` (in Nightly builds, run with -Z macro-backtrace for more =
info)
>>>>>>>=20
>>>>>>> For more information about this error, try `rustc --explain =
E0599`.
>>>>>>> error: could not compile `rustix` (lib) due to 2 previous errors
>>>>>>>=20
>>>>>>>=20
>>>>>>> For reference:
>>>>>>>=20
>>>>>>> # uname -apKU
>>>>>>> FreeBSD aarch64-main-pbase 15.0-CURRENT FreeBSD 15.0-CURRENT #8 =
main-n271819-5cbb98c8259c-dirty: Fri Aug 23 22:06:47 PDT 2024 =
root@aarch64-main-pbase:/usr/obj/BUILDs/main-CA76-nodbg-clang/usr/main-src=
/arm64.aarch64/sys/GENERIC-NODBG-CA76 arm64 aarch64 1500023 1500023
>>>>>>>=20
>>>>>>> # ~/fbsd-based-on-what-commit.sh -C /usr/ports/
>>>>>>> 87a38a839ab8 (HEAD -> main, freebsd/main, freebsd/HEAD) =
net-im/dissent: update package description
>>>>>>> Author: Jan Beich <jbeich@FreeBSD.org>
>>>>>>> Commit: Jan Beich <jbeich@FreeBSD.org>
>>>>>>> CommitDate: 2024-08-24 18:30:01 +0000
>>>>>>> branch: main
>>>>>>> merge-base: 87a38a839ab83c2def100a0975a7afb29e873cf2
>>>>>>> merge-base: CommitDate: 2024-08-24 18:30:01 +0000
>>>>>>> n674987 (--first-parent --count for merge-base)
>>>>>>>=20
>>>>>>> But firefox was updated to use: nss>=3D3.103:security/nss to =
match what was
>>>>>>> available.
>>>>>>=20
>>>>>>=20
>>>>>> Using devel/llvm18 instead got the same.
>>>>>>=20
>>>>>> Looking inside even a /usr/local/llvm19/lib/clang/19/include/
>>>>>> also shows the arm_bf16.h file is not present. By contrast,
>>>>>> for an aarch64 context:
>>>>>>=20
>>>>>> # file /usr/local/llvm19/lib/clang/19/include/arm_bf16.h
>>>>>> /usr/local/llvm19/lib/clang/19/include/arm_bf16.h: C source, =
ASCII text
>>>>>>=20
>>>>>> Looking quickly at more llvm* shows:
>>>>>>=20
>>>>>> # grep -r arm_bf16 /usr/ports/devel/llvm1*/ | more
>>>>>> =
/usr/ports/devel/llvm11/pkg-plist:%%CLANG%%llvm%%LLVM_SUFFIX%%/lib/clang/%=
%LLVM_RELEASE%%/include/arm_bf16.h
>>>>>> =
/usr/ports/devel/llvm12/pkg-plist:%%CLANG%%llvm%%LLVM_SUFFIX%%/lib/clang/%=
%LLVM_RELEASE%%/include/arm_bf16.h
>>>>>> =
/usr/ports/devel/llvm13/pkg-plist:%%CLANG%%llvm%%LLVM_SUFFIX%%/lib/clang/%=
%LLVM_RELEASE%%/include/arm_bf16.h
>>>>>> /usr/ports/devel/llvm14/Makefile:_BE_INCS_ARM=3D =
arm_bf16.h arm_cde.h arm_fp16.h arm_mve.h arm_neon.h arm_sve.h
>>>>>> /usr/ports/devel/llvm15/Makefile:_BE_INCS_ARM=3D =
arm_bf16.h arm_cde.h arm_fp16.h arm_mve.h arm_neon.h arm_sve.h
>>>>>> /usr/ports/devel/llvm16/files/patch-backport-llvm-db49231: =
`arm_sve.h` and `arm_bf16.h`, and all those generated files will contain =
a
>>>>>> /usr/ports/devel/llvm16/files/patch-backport-llvm-db49231: =
`arm_bf16.h` immediately before their own typedef:
>>>>>> /usr/ports/devel/llvm16/files/patch-backport-llvm-db49231: =
#include <arm_bf16.h>
>>>>>> /usr/ports/devel/llvm16/files/patch-backport-llvm-db49231: =
Since `arm_bf16.h` is very likely supposed to be the one true place =
where
>>>>>> /usr/ports/devel/llvm16/files/patch-backport-llvm-db49231: OS =
<< "#include <arm_bf16.h>\n";
>>>>>> /usr/ports/devel/llvm16/files/patch-backport-llvm-db49231: OS =
<< "#include <arm_bf16.h>\n";
>>>>>> /usr/ports/devel/llvm16/Makefile:_BE_INCS_ARM=3D =
arm_bf16.h arm_cde.h arm_fp16.h arm_mve.h arm_neon.h arm_sve.h
>>>>>> /usr/ports/devel/llvm17/Makefile:_BE_INCS_AArch64=3D =
arm_bf16.h arm_sme_draft_spec_subject_to_change.h
>>>>>> /usr/ports/devel/llvm18/Makefile:_BE_INCS_AArch64=3D =
arm_bf16.h
>>>>>> /usr/ports/devel/llvm19/Makefile:_BE_INCS_AArch64=3D =
arm_bf16.h
>>>>>>=20
>>>>>> llvm1[456] had _BE_INCS_ARM containing arm_bf16.h (and more).
>>>>>> llvm1[789] do not.
>>>>>>=20
>>>>>> I wonder if:
>>>>>>=20
>>>>>> =
https://cgit.freebsd.org/ports/commit/devel/llvm17/Makefile?id=3D778e212f2=
34a825c5e19612df4be2e8f838cb024
>>>>>>=20
>>>>>> doing:
>>>>>>=20
>>>>>> -_BE_INCS_ARM=3D arm_bf16.h arm_cde.h arm_fp16.h arm_mve.h =
arm_neon.h arm_sve.h
>>>>>> +_BE_INCS_ARM=3D arm_cde.h arm_fp16.h arm_mve.h arm_neon.h =
arm_sve.h
>>>>>>=20
>>>>>> was correct. I'll note that in an armv7 context:
>>>>>>=20
>>>>>> # find /usr/local/*/gcc14/ -name arm_bf16.h -print
>>>>>> =
/usr/local/lib/gcc14/gcc/armv7-portbld-freebsd15.0/14.2.0/include/arm_bf16=
.h
>>>>>>=20
>>>>>> suggesting that gcc14 considers the file as not aarch64 specific =
but
>>>>>> as armv7 compatibile.
>>>>>=20
>>>>> I got that wrong! arm vs. aarch64 have different source files with =
the
>>>>> same name (under different paths):
>>>>>=20
>>>>> gcc/gcc/config/arm/arm_bf16.h has guard test: #ifndef =
_GCC_ARM_BF16_H
>>>>> gcc/gcc/config/aarch64/arm_bf16.h has guard test: #ifndef =
_AARCH64_BF16_H_
>>>>>=20
>>>>> (More content is different.)
>>>>=20
>>>> As for llvm*:
>>>>=20
>>>> clang/lib/Basic/Targets/ARM.cpp has:
>>>>=20
>>>> if (HasBFloat16) {
>>>> Builder.defineMacro("__ARM_FEATURE_BF16", "1");
>>>> Builder.defineMacro("__ARM_FEATURE_BF16_VECTOR_ARITHMETIC", "1");
>>>> Builder.defineMacro("__ARM_BF16_FORMAT_ALTERNATIVE", "1");
>>>> }
>>>>=20
>>>> clang/lib/Basic/Targets/AArch64.cpp has:
>>>>=20
>>>> if (HasBFloat16) {
>>>> Builder.defineMacro("__ARM_FEATURE_BF16", "1");
>>>> Builder.defineMacro("__ARM_FEATURE_BF16_VECTOR_ARITHMETIC", "1");
>>>> Builder.defineMacro("__ARM_BF16_FORMAT_ALTERNATIVE", "1");
>>>> }
>>>>=20
>>>> which suggests bf16 support has 32-bit support (even if it is armv8
>>>> 32-bit). Looking for AArch32 state in:
>>>>=20
>>>> DDI0487K_a_a-profile_architecture_reference_manual.pdf
>>>>=20
>>>> it says (via the AArch32 column of a table):
>>>>=20
>>>> BF16 Supported if FEAT_AA32BF16 is implemented.
>>>>=20
>>>> Looks to me like the removal of arm_bf16.h for llvm target ARM
>>>> was incorrect.
>>>>=20
>>>>>> So I've put arm_bf16.h back into the llvm18 test context and =
sometime
>>>>>> after 3 hrs I should be able to report on a firefox build attempt =
with
>>>>>> the change (I hope).
>>>>>=20
>>>>=20
>>> So, it no longer failed for amd_bf16.h being missing.
>>> But it still has the lack-of OFlags::TMPFILE problem that stops the =
build.
>>=20
>> See
>> =
lang/rust/files/armv7/patch-vendor_rustix_src_backend_libc_fs_syscalls.rs
>> for inspiration. Unfortunately the exact patch depends on the rustx =
version, which changes a lot at this place.
>=20
> As far as I can tell, for rust conditional compilation with the
> likes of (leading whitespace details might not have been
> preserved):
>=20
> #[cfg(all(unix, target_env =3D "gnu", not(any(target_os =3D =
"freebsd", target_os =3D "hurd"))))]
> if oflags.contains(OFlags::TMPFILE) && =
crate::backend::if_glibc_is_less_than_2_25() {
> return openat_via_syscall(dirfd, path, oflags, mode);
> }
>=20
> is not just textual preprocessing like #if . . . #endif in
> C/C++. It seems that the conditional source still gets some
> validation processing even though it will not generate any
> code.
>=20
> If so, the error report indicates that freebsd is not getting
> a definition of the likes of OFlags::TMPFILE .
>=20
> I do not know if freebsd should have a definition of
> OFlags::TMPFILE (and related) vs. not. If the definition
> should be present, the problem is not local to the 2
> blocks of code that are rejected. If the definition should
> not be present, then the technique for handling freebsd
> for armv7 is not valid and the fix might also not be
> local to the 2 blocks of code.
>=20
> As I'm only trying to see if my armv7 builds can finish based
> on the limited effective process address space size, at some
> point I'll likely locally adjust the patching to cause
> "if false {" or some such that avoids the validation
> checking's rejection.
>=20
> I have no intention of running firefox --and I have no armv7
> video context set up to do so.
I tried firefox-esr (still at 115.14.0) and it built for much
longer and then got:
=
/wrkdirs/usr/ports/www/firefox-esr/work/firefox-115.14.0/gfx/skia/skia/src=
/core/SkCpu.cpp:146:27: error: use of undeclared identifier 'getauxval'
146 | uint32_t hwcaps =3D getauxval(AT_HWCAP);
| ^
1 error generated.
That is suggestive of arm7 firefox-esr having been broken
and unmaintained for a long time.
So I'm building firefox with the patching of:
third_party/rust/rustix/src/backend/libc/fs/syscalls.rs =
<http://syscalls.rs/>;
in place and it has gotten past building that code.
. . . time goes by . . .
In my context it failed for:
rustc-LLVM ERROR: out of memory
Allocation failed
error: could not compile `gkrust` (lib)
So I can experiment some and see if I can change that status
in my context.
=3D=3D=3D
Mark Millard
marklmi at yahoo.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?03DB526D-6B4B-42DF-B5E2-609E174A8311>