On Aug 31, 2024, at 13:39, Mark Millard <mark...@yahoo.com> wrote:
> On Aug 31, 2024, at 10:43, Mark Millard <mark...@yahoo.com> wrote:
>
>> On Aug 31, 2024, at 00:16, Michal Meloun <m...@freebsd.org> wrote:
>>
>>> On 31.08.2024 8:29, Mark Millard wrote:
>>>> On Aug 30, 2024, at 22:05, Mark Millard <mark...@yahoo.com> wrote:
>>>>> On Aug 30, 2024, at 21:26, Mark Millard <mark...@yahoo.com> wrote:
>>>>>
>>>>>> On Aug 30, 2024, at 20:33, Mark Millard <mark...@yahoo.com> wrote:
>>>>>>
>>>>>>> [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.
>>>>>>
>>>>>> I got that wrong! arm vs. aarch64 have different source files with the
>>>>>> same name (under different paths):
>>>>>>
>>>>>> 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_
>>>>>>
>>>>>> (More content is different.)
>>>>>
>>>>> As for llvm*:
>>>>>
>>>>> clang/lib/Basic/Targets/ARM.cpp has:
>>>>>
>>>>> if (HasBFloat16) {
>>>>> Builder.defineMacro("__ARM_FEATURE_BF16", "1");
>>>>> Builder.defineMacro("__ARM_FEATURE_BF16_VECTOR_ARITHMETIC", "1");
>>>>> Builder.defineMacro("__ARM_BF16_FORMAT_ALTERNATIVE", "1");
>>>>> }
>>>>>
>>>>> clang/lib/Basic/Targets/AArch64.cpp has:
>>>>>
>>>>> if (HasBFloat16) {
>>>>> Builder.defineMacro("__ARM_FEATURE_BF16", "1");
>>>>> Builder.defineMacro("__ARM_FEATURE_BF16_VECTOR_ARITHMETIC", "1");
>>>>> Builder.defineMacro("__ARM_BF16_FORMAT_ALTERNATIVE", "1");
>>>>> }
>>>>>
>>>>> which suggests bf16 support has 32-bit support (even if it is armv8
>>>>> 32-bit). Looking for AArch32 state in:
>>>>>
>>>>> DDI0487K_a_a-profile_architecture_reference_manual.pdf
>>>>>
>>>>> it says (via the AArch32 column of a table):
>>>>>
>>>>> BF16 Supported if FEAT_AA32BF16 is implemented.
>>>>>
>>>>> Looks to me like the removal of arm_bf16.h for llvm target ARM
>>>>> was incorrect.
>>>>>
>>>>>>> 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).
>>>>>>
>>>>>
>>>> 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.
>>>
>>> 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.
>>
>> As far as I can tell, for rust conditional compilation with the
>> likes of (leading whitespace details might not have been
>> preserved):
>>
>> #[cfg(all(unix, target_env = "gnu", not(any(target_os = "freebsd",
>> target_os = "hurd"))))]
>> if oflags.contains(OFlags::TMPFILE) &&
>> crate::backend::if_glibc_is_less_than_2_25() {
>> return openat_via_syscall(dirfd, path, oflags, mode);
>> }
>>
>> 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.
>>
>> If so, the error report indicates that freebsd is not getting
>> a definition of the likes of OFlags::TMPFILE .
>>
>> 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.
>>
>> 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.
>>
>> 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 = 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.
It is lang/rust's rustc that runs out of process
space in my context, not ld.lld or the like. There
was just one active rustc process.
top showed 3357Mi for the RES(ident memory) for the
rustc process at the time that process's threads
changed to STOP as things were being handled and
stayed there until rustc disappeared from top's
display.
Note: The system has 32 GiBytes of RAM and did not
have add any Swap Space use during this.
I'll see about rebuilding lang/rust without
-gline-tables-only and that is stripped. Similarly
for firefox then building. I'll see if the firefox
build noticeably changes for what the build gets
done.
===
Mark Millard
marklmi at yahoo.com
