From nobody Tue Sep 03 19:09:55 2024 X-Original-To: freebsd-ports@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 4WywDk3SdLz5Tp6D for ; Tue, 03 Sep 2024 19:10:14 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic301-22.consmr.mail.gq1.yahoo.com (sonic301-22.consmr.mail.gq1.yahoo.com [98.137.64.148]) (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 4WywDk17Vzz4Vbh for ; Tue, 3 Sep 2024 19:10:14 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1725390612; bh=0hqXl851gBsmuzj1KgEBitQqnwallhDpBdRuLp8yNCI=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=mXNyETj4NbVSG08DwIweYOF7aiqRls5UzKIin6FhPJ7DVfSdSrzDcmKFXfMp/S1lU8iQXAYZ9BFEzvFTCjmeQO5lYNN96okeFgN/gY+ll0pLyki56pxy/P78ySkWJh7qPG52DupDMC7NmKdRVqW6W+0c31eK1xhMnRf+P8pLDp+pAaTquqyma4I+cM+X3MA8gN3bTGJvlrtHEB8fYh344fWZbdJTAP/yEu+htmQdNt6f/h9PqiA0DzKpl/uwO1XMjn85KiiFjlrP8MIrnqLfvtvUXa5i7DKf6KYdS9v1Yy+B5F5sHdHr37GA3Jcc+sTz+IdDCnboAqjvcr9Ns/Lprw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1725390612; bh=t4dr7TNboLWiVC9tRHHdiPuPvGA7MZquR2Ze+41FvYu=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=BScbuD2OcXXUw9iOhTJEPtABRQEpKummlO+VtwBMhLbiD/EWqVWSTvCrpMhJcQ+cDTRyL+lWA0Jsi4WCegHHiqaM64zdGZLWgQBWY/QkzxKb9Thzu1K/VBc5JtWQLFydfPXQCwrlePqPYz/51SljCIuffqCe1sF3pnTmdEgxbLS27epl9VDK1wyUHkAkuFoNs6HPwVeev7bQu+eRt5D48R5h29MayRvZxoyyuAc1ufRpCxVUKU4PUWFDOVxJepTfzLOrZZwdSF6NbRrVBfRrmkAcqQW3Yh7Hop8uyMsrf50BvefyIdt1D/0ZCmoulpXvjbRQiZr+sMBXzoMkUZP+uw== X-YMail-OSG: qC7YMZIVM1mF7HDdJaZcXXd9WznkIztR4Jq5x04Sj1JfT3WmkQBlkq12gAe0WXg aPguI4YrpRh6EQNL6lrTyLO6K8_rA0f9cvCtqbrPMjnep6S8VZAy8AnN4nPlGWUvNt5lO9yGcbtj AgB8WVQA5ahxuT5Y9ECoblz_rSMRlXdEbkajuy63O6HLuTzn7fbfu7etki4O_Ei6XieIuOTcdRT. 643reheCE5aTLiUMp1RhpIcXvXjGROaOZDY2RhPlR03GdRYZiww5wAu1k0T.elmIkZRZ1vJ4CDOn HQe.7UR6Cz8hZIZCcSkeroqKgMLCqNC6PBusb.MvLFuAKxd3Kzvboeto0Epqd3.0ekDzVz7gDZjn Y6kQiREq33jf1g_Lab34Lbb86ow9V989OubnuW.Fcwml39_HE9JkrWkQKavCIT.MFV4YiW4ks.eR kkHU1kNkp82P_MhxkCat_yPgmvwpYklwHIsJ2MMpZ_nxp4yE.b7iOWr__MkMqM.jGH4fUj46EnSv tTlTrlCEVrYyidUU0ZWcwCFjzq5dsVrRvHOp2fuFCQoFLieTyYr7vFOpiRFS1Ku9T4KkgdDMBQKt BtOJHbO91Z_ocCcP5P3t8ieCob46Et9_J3s1N14bMiPLtaVilL7bymeYAVJE4rI8LIn4DGdiT7DV WsmwXP86R6dtscAEjmYU6LOdqUOJDYaKN0HfvJ9Cs2mwhzEimT9FS2EcDVo0p00fkf0RJWeEuDPg 8LIPG5NXQjZznXWniFzaERzZdhtUEo4KR1vUQ5zmssnhrmTAyhfi3GwR.jhcgOEjcmJPayshUy.z fm86Go.gwnDJvuuZ00mTCVRo425nP3I7y.S1tUtOAA0M0n2Shi_oecNp.MzQwDF2qMxdtTZXw_2k Gvr134OuLkp_IqhVlP2Ms0U3g8rVFb1rubiXpYa2etQP4yZUQso3KxOWBxtMV2mQv4xAziZpL3gW fulxtLf.sjEaHTtN6XxssHaeFsYELyHnhOvq__TPYZWktpRR_yH3aUeObDLfQL7ent4dX0AoUAnf JNxxouqW5z8VDqXN.gsG9dfgaQUZrK1xZRvloJk.mFYh6Pezw_LgWBkO5KLAxQwHvQ8bGEplz7ej ZCd4GF5HAD3H_duQSC8v75MKJR34jmlgNGUm8NlR3MCNd9w9AcWzbh5PQLJIhRKFF7sytYssa9Vb W29gplnsS6Zc0F7zusxR1apTKgGdc5wntVHRtJV8w3FFVQ5fc5LoQQu4N9KP_1AvrXv8Zw7IIAF. 1K4NElP81uCJvF2dVYSfSftChGBuB83b4cLWi5akvdvLC7sG52wPnLhIVViXGQUfO9KLBM0NYZQm PNxUNhvz.oGAVBy.KSTgt7OgvdgjAk3Izm5LL35Nw8z6le6MonF2v3NyOR92T4aDucy_JyGuyYR8 49ekDiw7xXMryZ4DXm0O3MdIpZriY_zLZeuF6adXst0_ZZ0PbDHMfpmxUKyX9x810m1mkwZf2OER cy4RjBo3F.D2KPlbZMKUPNwFiMewH2KDA4myggBcWuzvuTaZ9eVj4DsloPDAy3Zly4vUKhjUsB83 r65C8_9g0WSWQZ8EU7DgnWbcqvqCrNU_YVpiPMKivlm7rPDYTXBpqD6O7OLQg25vIQgrMUtzGGMY dCV7BcDWXSPQPlEl0TSxeCfX8UKrxVyvCwO_3ncWNJjN9S8DEAbvoyPmuYb5W61B3o6vvR8ar5f2 j1Yr64ci7QrfpmMd6WyDTIrCP8xfMxqCHdb7mn7QXv83h1ovZy7sdCxlAdx7uXFXuKwMOX5zy8Yt zIWCxUtWZFnlPPxY14xQMQGHIowHcTM7_eRvi158GnGafEfZDpfMWd.X8I6dhFmDdBw2YFRBWZ4N SHLK.LyvwMg9.ixNfbY13vMFxTx9gI9yfdwuzgY_le2hLov.tlMirpgjRWMYeX3oq1WKLXa5Gn_l Pu6NUNIv2ZpxZvv6nWSew0..Pat2HBkfp4wLmD9Fx.9BaP6_HDpC0TSfIcpiLWnrCksYYIZ2k42S QQlobG8fZnZc4LSjpATS2AXKzwLZ39kGm4d8lZdwZSn3pqN.Itu0FwOTZreLRd_MSAjl0QeFlJOj KMMH_LxNPcCRzpscTxfNewWlRphOcpBboV1iWQiCOkROSRmK21.AxPPyi0rseind1MY3NI27bcIJ tZHiP8C6ehJYJU0zEt4d.l7_QQ4S2rz1R..4L9fGiTsqck511Ek2whJRbp16keq.zvSzy_1FGAvy hQUZ81FhiktnfVQjoPpLtMpSbSigSQx8q0F7_9639vnvzxyGjK66UoUEP7pKCqZGyEoT68BIK5pM S8k.Iwe0Uv7Fy95v26Bmigi.7SnsAiQs0ZRxI X-Sonic-MF: X-Sonic-ID: 5a94cd80-a0e6-4fd0-b779-7014e27d003b Received: from sonic.gate.mail.ne1.yahoo.com by sonic301.consmr.mail.gq1.yahoo.com with HTTP; Tue, 3 Sep 2024 19:10:12 +0000 Received: by hermes--production-gq1-5d95dc458-s958r (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 1b474be95e24b56052ab0258afffbdd1; Tue, 03 Sep 2024 19:10:06 +0000 (UTC) Content-Type: text/plain; charset=us-ascii List-Id: Porting software to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-ports List-Help: List-Post: List-Subscribe: List-Unsubscribe: X-BeenThere: freebsd-ports@freebsd.org Sender: owner-freebsd-ports@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: Tue, 3 Sep 2024 12:09:55 -0700 Cc: FreeBSD Mailing List , FreeBSD ARM List , FreeBSD Toolchain , Tomoaki AOKI Content-Transfer-Encoding: quoted-printable Message-Id: <5BEBBFCB-A877-4124-B07F-D4C6D25B7026@yahoo.com> References: <75609A57-7B50-40F5-88A8-0278CCCC018B@yahoo.com> To: Brooks Davis X-Mailer: Apple Mail (2.3776.700.51) X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US] X-Rspamd-Queue-Id: 4WywDk17Vzz4Vbh On Sep 3, 2024, at 11:12, Brooks Davis wrote: > On Fri, Aug 30, 2024 at 10:05:06PM -0700, 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 > The commit to the port simply refects changes upstream which made > arm_br16.h aarch64-only. It was done in a massive commit = (a70cf56d20b956) > so may well have been wrong and no one notices because they always = build > all the backends. Hmm. My build in a armv7 context with arm_bf16.h listed was of: ---Begin OPTIONS List--- =3D=3D=3D> The following configuration options are available for = llvm19-19.1.0.r3: BE_AMDGPU=3Doff: AMD GPU backend (required by mesa) BE_WASM=3Doff: WebAssembly backend (required by firefox via wasi) CLANG=3Don: Build clang DOCS=3Don: Build and/or install documentation EXTRAS=3Don: Extra clang tools LIT=3Don: Install lit and FileCheck test tools LLD=3Don: Install lld, the LLVM linker LLDB=3Don: Install lldb, the LLVM debugger PYCLANG=3Don: Install python bindings to libclang STATIC_LIBS=3Don: Install static libraries (does not effect = sanitizers) =3D=3D=3D=3D> Options available for the single BACKENDS: you have to = select exactly one of them BE_FREEBSD=3Doff: Backends for FreeBSD architectures BE_NATIVE=3Don: Backend(s) for this architecture (ARM) BE_STANDARD=3Doff: All non-experimental backends =3D=3D=3D> Use 'make config' to modify these settings ---End OPTIONS List--- Note the ARM (no AArch64). It built just fine. When I looked at how arm_bf16.h is provided, it looked to be built via llvm tools and is not direct source code that as been committed. It looked to me like arm_bf16.h for an ARM build got ARM (32-bit) content. (But I'm not expert.) The firefox build attempt found the file and got no complaints about using the file. Sure looked to me like it just worked when it is also listed in _BE_INCS_ARM . =3D=3D=3D Mark Millard marklmi at yahoo.com