From nobody Sat Aug 31 20:39:36 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 4Wx6MX5nvJz5PWpQ for ; Sat, 31 Aug 2024 20:39:52 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic316-55.consmr.mail.gq1.yahoo.com (sonic316-55.consmr.mail.gq1.yahoo.com [98.137.69.31]) (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 4Wx6MW344Nz4kT4 for ; Sat, 31 Aug 2024 20:39:50 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=YfDBh6kb; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.31 as permitted sender) smtp.mailfrom=marklmi@yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1725136788; bh=zY/bQ8kBPbRU/lbvLDmik9BIq7aIxZJR9N/z5X2P1ns=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=YfDBh6kbxzdBiT07NC5Lq8aXthrJpWFJw9pNB5uk8QOS3B6zEScSM7G6EYeNoJZKPgKdDQEYorLVhUaBvWF2gw+J+OrYolievZqaqGoW0JMY0m8TXS2vuxUxtXUBykAMKSCAo6Y0JgfDcFgAMA6yr0FN6bX2Yu9Ln++JKbGb9DOO9I3FA11GjpfsSNBbqYgZrk6S7qgOeFgkOyJZ0o+fbVKbSHX8m+GMo99TjKSwhxMTEjUFlqxZa68OzHJZvDVH2YKTr9T5livgr7J7HrfYYWXQZgp6d/JQkEFHqoQcuXz1fEaOvL1Xhjnhu3FhwGIcLFUmGRZC9/mEU1TwS7c21w== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1725136788; bh=pBn+RoRKgdrwNPMCQGi7QMWMw5pvSlEXIoL2EZvR3Io=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=UVwjvXK39TZkie086q/Vp/BR8qfQ0/WIdScaa6AjSPKykL642LtqvvwayQXukWcNdGioLF8jWrIQUxLZ8SU+s0X6CP0Ok/pLyr8eE7/Aou+1f8eAiMMjlgzbDnQj/syTlxS8VZyNfcamB5Jp9wUgtVe6OYGKnaJuKZO38C/dF/uMZJjzokD45xn+W7lJQa+bqkdDOdD/A9BwSGt70EFeE/SZTZ/PF65ZIKUjL/1+i7pVKYvEzfr0Kfi0S0N0dl7XacSfQn+EI3yiUmnsRbbLoA7gE+ge2XKi9AHzfi3d5w0HDq8G745QKxSUnQPrkVeTGR6T+9GwUi6/g8AZOswUVQ== X-YMail-OSG: 8qb_0VEVM1n6P.XgjnJne5CZMDGAyGkxi1mblOIfYtC_ARt3LZGvj29GmUEdrYB Z6j_FWxzBAXmznIUL7RPCQcSH3teFq4m_a.3RonCG6SYiKNcoWtL9Ahlu_j.hiQRXgKtO4GEFG.D 3AWoS9V1st82IOrLLk6OVtuOwIpWKmD6jOrWg3ufBeFtXWq_EJMiTiLOfZBUc8tLjGIIBX_56qQp u3VBWz7OZu90sKxB6ffshK.1Zk5AN_RUnpdMStmUzWuKx4gikIkUxw1fajU9TP1YUdVV4uUePLMi QGnUX.RcV1VAtREzdzmSD_zonOsGi3RJGTiWFM_eyhtiJoetxMS38644qu4NmOO0MMOvMUKXRdcu ZdWMrGxYgA_xxSauIUhnZQGem3KMWU6wnQtCzWfgwBOKeDkGGIKBPCiroSHiKavGSWvMQI2XR5FS cCYbXZu9JPL2VBa_pZZW4X48L1kFB1VkSBIw421_Y5y49508lnBdqmTaRY8dKeQ9ss6XK9_wToC5 y6SgNjerFiQOdlak5AwdMANq7YrB9crVH3WOgCMZEnTirdKcw4av7LoAXnWSG2e8Bb_.1BobfNSc jCPe6YjPqcq0TBgd5g9_CJbvBjXG3DB2wpk1TnZ3tIePNOyGbt3_rj.XjNld.Arw.ZIsswWMhkOg 3vCtiKnZt1l2.vRx8GR6xZX2dgG.IXnATy94PC1ZDqz4X0r7J2u9C_JxMCsvTZOUDDkPvIHm5Vs_ W0T0p_5VX6mvl6CVPRZM4L7QmPQqifHqGDgHQTeYk3PNQUhXQ43cLjTxZb5lFPeEdsCMlQBCLukl LgCLMPxtyURdIQK5KhcbrtJQRmI8.AsXIukwZBexC8rzNQYNMYYZwUG.JQQYOZSXr4vyqUdGYPLE vUAW80h_PLVfuy7SkT9Bf4CzqJ5IHv5NlNEp6SUaxhW8xL4yBytpohYE_ASjIqZwrdnEgQndDOEz abBCbcESAph2YGkOZwa5l9fUuHDEQux.n1mhI7eEI_s2G.8.JFYISl5tNdMSuC4Y27dWOTQEVEoV sqnsuM.hkvtKjF6zQiueECp7.7DftDmc5Kbd312W_8T1U2leKUHJQdhXRc7kCdTJyAUqonhbrjG_ tONDJf3ebzQuZaNuxrg1R5YjCLEL9fwEV_LRZpsz4YKGl3ykf1olRfCgfo7Pxmh42Vl2wQNMZuW4 IKPK8cjPubuI6kwodWJNiHPb8VIraZZNaThgf8NinK72q9W0bpdqfHhriOULe90b_rAF9FvIQFPE qkOUE_QvOO9wIJKlNET5iNLp1TrpcjaxUif8oVzrypbu2S_lxBYgZZlsdU3E7.3mAte753VO7.Bx nMfBMckPkF2fuw1agxjLt0gv.oT36OGJK0KM9stw1R.j5M_YHEHPLcnrClD6QLfAdPtcr44MunTy kPBjsR0qD_NnJa0EadwzINBnmI8l8Y2Oe8bXpyAMpuADW_aOZ6AWRb5zyHkkj_yAbKM3fEj_if_d mQn3WfXNzdqcv9Ynv4GnUmGti7tBjDLwSmOJxTepid0JUV7UzEv0mxgH8q7v5Yia51rONzAoyfFR lOCPE3fCTZLUlas24rhIQr69WKTz6e5PwVMcH3jKfuP_s.OdVzIlhofDZoc_lQRX2z6ltwZ.9GgN 3mkwnVucAdp.wcNZceZxHcBD2m.AXij2LmE1s8IWjy6hHzUS5F6KeQVgmi0n189A0ko.pBRUODWY c8dd2jIwFxEp6Un1PqS7VLtO2p0ivC.gW66ooKJ6ceFg_n8YlMHsCs55ojBC9Zo3a9XkG8qFq6Ex s7cZoTWqDIofPQ2jFCUxbIgR0m_sv3LzK1Nd8nq_xZtSmYr4X19ZulBwzsDjdbeJwyNTPP227m5y P9vncLeLcbvYaVc7fwvqqFH5G_.NScRwFzI2HCFcEMSB9gUPWTZZtKnBGFuN.z7rUiOGQCHpABYF qV_u99XSUf1C1H2eFX.xYBZehoBs5mLIMUwM_1pUi8gXalP59PlJDDBa1EXRcUx.A7f4JaLq3lGL r5MQ6tJd2DLkvZ1NDmguNaYt1hzdJQY96rH1HjlogyKAsCTjXSw_uHYUv1BlvZfseFQ5y7afeJgw GKqK8NsVL.8KUyGTtRsKBGdAO_otAvHS_7K_2HZXVYTJId.XCRD5TMYkXE2OJoYTmAZy3BUJ8R7S OYOkdCPHDtaPDh38QyzNvclbLkkGCHrLEBOGiHAGt9JfnPbLIc6kXofYxvNoNWCSYZGI6g5dTfrQ kvGvAZrcmqJgS.M8FYNHM6G895c9M35CK8Lpg3ckzr4UP7HofV6mlC52AKJ2Q916zBM_R6pVWnEV nPdXadXF1oOqb0Lp0abIwYnrTYBOBOMzTb5ZjpMS5o.lhKBQi.pN3 X-Sonic-MF: X-Sonic-ID: 9cb316fb-0406-4649-bc0d-ad1c91e03768 Received: from sonic.gate.mail.ne1.yahoo.com by sonic316.consmr.mail.gq1.yahoo.com with HTTP; Sat, 31 Aug 2024 20:39:48 +0000 Received: by hermes--production-gq1-5d95dc458-dxlpk (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID af5c71900c01927a8f3cd3cd213f50a4; Sat, 31 Aug 2024 20:39:47 +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 13:39:36 -0700 Cc: FreeBSD Mailing List , FreeBSD ARM List , FreeBSD Toolchain , Brooks Davis , Tomoaki AOKI Content-Transfer-Encoding: quoted-printable Message-Id: <03DB526D-6B4B-42DF-B5E2-609E174A8311@yahoo.com> References: <75609A57-7B50-40F5-88A8-0278CCCC018B@yahoo.com> <24D56998-0939-43D0-A98C-E398CCDA0AAA@yahoo.com> <71a16edd-94e7-4a06-9a34-59f17c442a96@FreeBSD.org> To: "mmel@freebsd.org" X-Mailer: Apple Mail (2.3776.700.51) X-Spamd-Bar: --- X-Spamd-Result: default: False [-4.00 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.998]; 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.69.31: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.69.31:from]; RCPT_COUNT_FIVE(0.00)[6] X-Rspamd-Queue-Id: 4Wx6MW344Nz4kT4 On Aug 31, 2024, at 10:43, Mark Millard wrote: > 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. 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 = 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