From nobody Sun Sep 01 02:17:42 2024 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4WxFsh3QHsz5MYp8 for ; Sun, 01 Sep 2024 02:18:00 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic303-23.consmr.mail.gq1.yahoo.com (sonic303-23.consmr.mail.gq1.yahoo.com [98.137.64.204]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4WxFsg2Tcsz4KPY for ; Sun, 1 Sep 2024 02:17:59 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=idzEJBj+; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.204 as permitted sender) smtp.mailfrom=marklmi@yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1725157077; bh=u2j1TelUnbDh0ioDCGpJOVZHJ8VoOZ3wmfkOEhDFIvA=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=idzEJBj+K8RVJ+0maFPggmLmLN3JP0ZvGsO2CK/04ZG9d54XFfsQ9TYtL9buF4QEC1iRqKjmiBZASYSiK9getXeQ2598end/eGqyYNN+UOQ34MmhZS1MRXgIrInRIqcIwkzzeEOcrx5Z0AC7ku4r0NHmazsfqDoSq60KLe8/LfyA1pjtKOB8jaqsq33Mr4pOelifbNxl/SOl4CCOC93asSHK8ChnNOmNFK05OFeEAT7riyCk4ZJ839KsMvaoO11X4Fj58Rvt82ucWstqZNee4xovamydYCLzNmfoEVcHh80jMLkl7e9fd/510t1cFPDQKddEI28hDE9mgPuc8AFYGA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1725157077; bh=RM8TB2OMjNYSNTERkHvyuoosWEs3ZcJotL682GIjoxD=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=CszSpjOzjcTqGU3t8ngRXYRB7eS+KDzDD88c1OIDBPm4Msb2gXdO6GvnQX3BZqzpzsxuTtizcnA7XQPL7WnllY+C2W+88B/lPt6uLhpamEt/lAAo5geYXgg9HC3TJlK92ABzQ/teUPRAd45zFv+9s9HP/hAy6H9LleazBaHe1Ai8TXC4LWjclggVD8Q6dv6LZH8mxw394OPJBwxF6hIfkTYsFTI0lJIM0h8NnhLoR+sbolawszTdlx9FkAshLiUsE8EtJVntzJVY0VXvVV33NTN9kNMFNMunxrXWoHQ6eM61ttKKcBZC/zr6JXjQimGcQ9zEHrQAcxYlx96Ow73McQ== X-YMail-OSG: bA.KXqcVM1mWDra6n2rEuvQTlqBn4GXYLu2FqmWtFJP413x7jlCyWWWmL8yvVyE XaXXePs5KeVRXr2C0VxbbsYW.DvqcUcTRjHFbQnn_R83ELHnxtuX0tpzJGrV7Aov8VvlqumhXA0C RYej3czBJKMnoMpI4MwHPFtNrXkaBELBfIHFuoUy1ZWuhtcEcr1cWpatX3aGPLO1fVTEXsVGQ7Pa I8P4yRo.dVkCwL0LweMQhDT2PBERROgUF.Kz7uSs.ky9zULOjAbBxgSnyIKSNHkzYPX1qndDG_mz dK.3XIa0rUXJ7wyT_ettJv1i35iE4sz6l01.IDHV6O6kTRbOEY.qgdSRBYOtE_1GMqDiY6MamlrP 1PyVjts94rqdlUelKAO5GOxhwi0UTBhSiodL0EUQTYjzxdY5Fh13yvLxVEP6cKdMTwovOf2FbjHm T3q_DcywjrWdFZlOtDkLCPVInIpKCfhhMaMaw5CMTZHn3UNTRMclWhxycz4h3xQ_oPab7E1op9Op pBUU3sDi8q53OoBpUJ6UcCaGFYjwLu4CfHACX_abwQgbDMcP8cc1LN_LfmRgtgIAWu2RvQBk_ELt A8rs.no9TUDqrAM_.seIJzgmv6Pz.ZaAKmS98iziYabMo1CxaiXPX62cnTcIrEIfGH3z9_EkBjpH QpsuYKhY7gpqfPeqJwI3qhbe6RNV34LiXDj8lXfAZ9GYiur3mNy0hCOQTZ7OT66vly0jvHEOdOC0 P4OLvr7Dlqua8t8A5S9ExRJ9AUTOoqMd9qKbl9XHIOWwK3Xy9ooIDYWjM.ji7P13zWhX0XD4ofeK 81MEtU8aaES26TQs__ZMdosimxZuiIAd47vA5sL4vv7fispwXwsVDhSLsqW5i0gypVeADtxzSL1F FfLFM_Vo1XgEtyXzFob7z10Xa0GtLdC11ORMf5cJD2YYOX5oJC0O5eqSA0ojGtStMAS4GABfrCF4 Mk8UlFduulu67rWq.zgzH3los4PqnEHBZqfEtW44E1d_M2CHvdQ4QCi8yxG2XQnZEyDIcmklpdZ4 IVNjIZFI_yK5nuLw5IiEVtZpnAzl6Z1HzXOF_YLHCO3Y71s1HsfAUHaf9.91Qw7GZFOPlCgJrM6E iBjbRPSixZoR6Q1M23ZAuSuwipFdFkJmeyFBKBKClCfM7DCyNymk1qilkYozlqxmQl6j0uM2xQ8A MmiEAj3XIlrPNWePKmepnsB461agzM7xak_rDIchWlyWOU0zF6HYXPlCAc8x84r5UpC8zST6TCHD pBE_wQp7Uw0CBm70KFK0O4By3.H8D3TcncHK0nQSXq4ajyJhvWwTMU6fEl2Qn9IiYyvtsi5NPZl7 QZb6AxWdNfCho2K.fXEokYAAwK019pRD.mB7PzCmpi.pbZ.h20tp6MTuukpmRXPKTRJ.3.WhT46a O3WDIequ6wsDobIGce4kSQZI98RQ8GetrnG6fWs_wbdIdeSzCKjtHHL_AfqP1BEZXp0RCZIslDbf Yo.gI35gv_hoyFM5jt_DqvNSmpb41Ncys6WTwaGCU0sRDwWby1J5ncy5kkZ3WBD3ziY2mGVqLWL8 .h7qoVoaPsSHccAzAwOMlGILXPPWwYJ36RdX5IXZaErW6ea75SuUpKat2162XWZ2ape0fXBjP7Gf 9asxBTjv4z2uvkqDcG1cABkCVt5vobwGidohhpTxcOT_BOliLDTaShc5YF9pGjlghfXUc8P2kK.q sUP5IFWEt3GYutsu2f9xIRv_BgqFXVAqb9K19v_BwTqIIIbaOCeWOCN5JjV1nbaPLAonj7TOu2Ch M7PHLSa9oIYWFFiwm1c9QAUnZr1oqluGHwXvlh3a_UCpBmbEM0fumu6f87Omn288vjcJ6TN_fNuf bzMn5zc2ANAcIfjfeqWSKZg14tlH..AVOVqwgUcLlNJ5T3uhn5Vgh8KnuLBN4H8VmamOjILUMQmD c_Qk909LVt_A_R_9vNImQfUGua.TLIPbLEt3G4_dDZrGqAdF_Q9dcTLuPoYMmwLQXT8LbfxpVcR4 AWVIQ6MYdrAAxpHY17EEzV2S1tWJIDgBbwnNe22NDoCCbr2GzokB_9BUPAWCo2C4ZM1w_.RREnpR d3JkvYVoMlmbZJYiS0MQ1Fytpupig6aDdL20JwUVwMftQkuj7pHaOaGLW4vmmhY8MD5wskIg5AHE 4Ha3fbljKi_Qfj4euQFlYX1j2Aei9kvwSfS8x5fdcnHkUnbGt5zXKXnC6TBlm8SsVIYABwO1tDH2 o9unWnf2kfPNsD_gBZBVMMWJ.kURH7qLr18xv0B4.N3DeI16y4GeypExBn9lQSij.m5ncntK48U1 U1_mDAaVxjSbBjJeFoxFOIu8coleQmlKTaghu_NH67A-- X-Sonic-MF: X-Sonic-ID: 143af61f-bb3e-465b-8f06-a64807efc080 Received: from sonic.gate.mail.ne1.yahoo.com by sonic303.consmr.mail.gq1.yahoo.com with HTTP; Sun, 1 Sep 2024 02:17:57 +0000 Received: by hermes--production-gq1-5d95dc458-24x88 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 0b5bbd251e5c37d010778e5a903d760e; Sun, 01 Sep 2024 02:17:52 +0000 (UTC) Content-Type: text/plain; charset=us-ascii List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@FreeBSD.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3776.700.51\)) 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] From: Mark Millard In-Reply-To: Date: Sat, 31 Aug 2024 19:17:42 -0700 Cc: FreeBSD Mailing List , FreeBSD ARM List , FreeBSD Toolchain , Brooks Davis , "mmel@freebsd.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <75609A57-7B50-40F5-88A8-0278CCCC018B@yahoo.com> <24D56998-0939-43D0-A98C-E398CCDA0AAA@yahoo.com> <71a16edd-94e7-4a06-9a34-59f17c442a96@FreeBSD.org> <03DB526D-6B4B-42DF-B5E2-609E174A8311@yahoo.com> To: Tomoaki AOKI X-Mailer: Apple Mail (2.3776.700.51) X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.78 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.78)[-0.782]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; TO_DN_SOME(0.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; TO_DN_EQ_ADDR_SOME(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; FREEMAIL_FROM(0.00)[yahoo.com]; FROM_HAS_DN(0.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RCVD_IN_DNSWL_NONE(0.00)[98.137.64.204:from]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]; APPLE_MAILER_COMMON(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.64.204:from]; RCPT_COUNT_FIVE(0.00)[6] X-Rspamd-Queue-Id: 4WxFsg2Tcsz4KPY On Aug 31, 2024, at 14:59, Mark Millard wrote: > On Aug 31, 2024, at 13:39, Mark Millard wrote: >=20 >> On Aug 31, 2024, at 10:43, Mark Millard wrote: >>=20 >>> On Aug 31, 2024, at 00:16, Michal Meloun wrote: >>>=20 >>>> On 31.08.2024 8:29, Mark Millard wrote: >>>>> On Aug 30, 2024, at 22:05, Mark Millard wrote: >>>>>> On Aug 30, 2024, at 21:26, Mark Millard = wrote: >>>>>>=20 >>>>>>> On Aug 30, 2024, at 20:33, Mark Millard = wrote: >>>>>>>=20 >>>>>>>> [Subject was retitled.] >>>>>>>>=20 >>>>>>>> On Aug 30, 2024, at 16:24, Mark Millard = wrote: >>>>>>>>=20 >>>>>>>>> What my test-of-building got was: No 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 >>>>>>>>> | ^~~~~~~~~~~~ >>>>>>>>> . . . >>>>>>>>>=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 >>>>>>>>> Commit: Jan Beich >>>>>>>>> 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 >>>>>>>> /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 \n"; >>>>>>>> /usr/ports/devel/llvm16/files/patch-backport-llvm-db49231: OS = << "#include \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. >>=20 >>=20 >> I tried firefox-esr (still at 115.14.0) and it built for much >> longer and then got: >>=20 >> = /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. >>=20 >> That is suggestive of arm7 firefox-esr having been broken >> and unmaintained for a long time. >>=20 >>=20 >> So I'm building firefox with the patching of: >>=20 >> third_party/rust/rustix/src/backend/libc/fs/syscalls.rs = >>=20 >> in place and it has gotten past building that code. >>=20 >> . . . time goes by . . . >>=20 >> In my context it failed for: >>=20 >> rustc-LLVM ERROR: out of memory >> Allocation failed >> error: could not compile `gkrust` (lib) >>=20 >> So I can experiment some and see if I can change that status >> in my context. >=20 >=20 > 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. >=20 > 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. >=20 > Note: The system has 32 GiBytes of RAM and did not > have add any Swap Space use during this. >=20 >=20 > 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. Looking at the log it turns out that gkrust builds using -Clto . This is despite the LTO=3Doff in: ---Begin OPTIONS List--- =3D=3D=3D> The following configuration options are available for = firefox-129.0.2,2: CANBERRA=3Doff: Sound theme alerts DBUS=3Don: D-Bus IPC system support DEBUG=3Doff: Build with debugging support FFMPEG=3Don: FFmpeg support (WMA, AIFF, AC3, APE...) LIBPROXY=3Doff: Proxy support via libproxy LTO=3Doff: Use Link-Time Optimization OPTIMIZED_CFLAGS=3Don: Use extra compiler optimizations PROFILE=3Don: Build with profiling support TEST=3Doff: Build and/or run tests =3D=3D=3D=3D> Extra cubeb audio backends (OSS is always available) ALSA=3Doff: ALSA audio architecture support JACK=3Don: JACK audio server support PULSEAUDIO=3Don: PulseAudio sound server support SNDIO=3Don: Sndio audio support =3D=3D=3D> Use 'make config' to modify these settings ---End OPTIONS List--- So I crudely forced -Clto=3Doff overall (RUSTFLAGS and CARGO_RUSTFLAGS) and tried again and it stopped for another reason in media/libtheora/lib/arm/armcpu.c : #else /*The feature registers which can tell us what the processor supports = are accessible in priveleged modes only, so we can't have a general = user-space detection method like on x86.*/ # error "Configured to use ARM asm but no CPU detection method available = for " \ "your platform. Reconfigure with --disable-asm (or send patches)." #endif This suggests armv7 www/firefox has been long broken and unmaintained. But avoiding lto lead to: Finished `release` profile [optimized] target(s) in 18m 40s toolkit/library/rust/libgkrust.a instead of running out of process address space (or suffering fragmentation based limitations). Overall, it appears that armv7 firefox is broken in multiple ways Similarly for armv7 www/firefox-esr. Absent anyone actively spend the time and effort on getting to an operational state that would be maintained for some time, it is probably best to just have the Makefile indicate BROKEN_armv7=3D for both www/firefox and www/firefox-esr . I did not get so far as finding out how long an example build takes. I've no clue how many others issues would be run into just trying to have a build complete (much less be useful). And back to where this exploration started: the BE_WASM in status devel/llvm1* and how llvm19 is starting to change that. It would seem wasteful for devel/llvm* to build BE_WASM by default as things are. BE_WASM's default status could be changed back to enabled if/when at least one of the www/firefox's that would use BE_WASM becomes both buildable and usefully operational on some example armv7 context. Until then, BE_WASM disabled by default seems appropriate to me. I'm done with my explorations and will be putting my environment back into its normal configuration. =3D=3D=3D Mark Millard marklmi at yahoo.com