[Subject was retitled.]
On Aug 30, 2024, at 16:24, Mark Millard <mark...@yahoo.com> wrote:
> 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):
>
> 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>
> | ^~~~~~~~~~~~
> . . .
>
> 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/rustix/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/rustix/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
> |
> . . .
> = 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)
>
> . . .
>
> 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/rustix/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/rustix/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
> |
> . . .
> = 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)
>
> . . .
> = 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)
>
> For more information about this error, try `rustc --explain E0599`.
> error: could not compile `rustix` (lib) due to 2 previous errors
>
>
> For reference:
>
> # 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
>
> # ~/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 <jbe...@freebsd.org>
> Commit: Jan Beich <jbe...@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)
>
> But firefox was updated to use: nss>=3.103:security/nss to match what was
> available.
Using devel/llvm18 instead got the same.
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:
# 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
Looking quickly at more llvm* shows:
# 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= 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= 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= 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= arm_bf16.h
arm_sme_draft_spec_subject_to_change.h
/usr/ports/devel/llvm18/Makefile:_BE_INCS_AArch64= arm_bf16.h
/usr/ports/devel/llvm19/Makefile:_BE_INCS_AArch64= arm_bf16.h
llvm1[456] had _BE_INCS_ARM containing arm_bf16.h (and more).
llvm1[789] do not.
I wonder if:
https://cgit.freebsd.org/ports/commit/devel/llvm17/Makefile?id=778e212f234a825c5e19612df4be2e8f838cb024
doing:
-_BE_INCS_ARM= arm_bf16.h arm_cde.h arm_fp16.h arm_mve.h arm_neon.h arm_sve.h
+_BE_INCS_ARM= arm_cde.h arm_fp16.h arm_mve.h arm_neon.h arm_sve.h
was correct. I'll note that in an armv7 context:
# 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
suggesting that gcc14 considers the file as not aarch64 specific but
as armv7 compatibile.
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).
===
Mark Millard
marklmi at yahoo.com
