From nobody Sat Aug 31 21:59:00 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 4Wx87B4Lkzz5Pdj2 for ; Sat, 31 Aug 2024 21:59:18 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic303-25.consmr.mail.gq1.yahoo.com (sonic303-25.consmr.mail.gq1.yahoo.com [98.137.64.206]) (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 4Wx8792VWYz4rDc for ; Sat, 31 Aug 2024 21:59:17 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=Aj6t7Ohx; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.206 as permitted sender) smtp.mailfrom=marklmi@yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1725141555; bh=O697T2dPkAQfy5p3fuBqFCx/e7x8bu1ZJyz8m28PY74=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=Aj6t7Ohx3vszbNDlur1xLU9WtL4C26KhFZb554DO1Icqq69avcA1Sn0wRQyltOgw6mXUs3C33Uh5KkPpFUOfaQ42rpNix8X8eoK9voR5uzKJOgkHG5w+zNhpg2AVr/VzqoSXR09HH7ToVsLLZh8h++x9Y6kdF0snVfX1SJUak/5mCe8koAnbdbKuxFHpqvzRbD7ExM506wmgQlslJ702Wim0Opic7gEYrZEWlYOjk4vSetyJ8elxX6feLntMCtk78MI8E78JaIvZoIq+tVqfCPc/K3R5Dxv6m4GHBzUQllBEHhW/zbtgKX+D5tQbMaMdltn1bczV5mKse/ShN9zQSQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1725141555; bh=b0zB2MfK3KlmtP6wTDvFvIg6b852wS41YnTL3bSvDc6=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=Qf6NLMcOI0XmPWNFugjblrJnsxIX762FbtaE543XpnGlkst/kFmcXjFWQbaZKQUMq2fQ07+oBrt8hgEfJlsgD33IXI51ca6Iqu5wl29fyhYOTVV6+nxCQaffBnWyroKSEnoej3p8TmansT9N1UPpH0KePBpsp+0mqEN+CboqAO0Q2Lk7qdEW5Q9LQzm9HhSL6OztD5eDgPvRza/H5vdlYznFLqHL0LquNVJC4/h4qKujrCO3f3bM+bXKzWAOV8aK1tiHAztBEPTiXcD3PItVnRAu8GsTv5wHtgofwDJ1f3V+1BsCPbXaQiL7QErlsll66/HeatS4nTZ0N5gPJ8HQnw== X-YMail-OSG: dZpsF3EVM1ldyeRJsL4YQxJX6nyCBmznSY61.ZFP8dFfSXglLjOg2w4EZ25ip07 brLy0UB48bJQ4CN8C9PDMEnyMC8u5eNEt8NroOOXtqNsWfAE9a_m4JGdbvG5XPOFze7F0IJ1HRDY wnAr_V.A1gG5Z2XatxmToJ46ybKtPJl63dgMVal2MLmVbOOn1Qz7uh9M2_fNZRpEiQR4siIC8Gpz rdBiNPkd9i3jUmBMVcyj1oaRggkIsvv3sqorQsW3pEGDZjXVSVz_eHkJ2nt_pyCpod7YQ0AhL.ib ystLulDpagqASE0SukhActZS0tN04kM9IMptrkBP7o4bDAZs2BByhsQpEKuYJHAaUI4bS4y7f2u6 d13lCdDnpxSC1nEhhxOXrw27.3Q1xGDeKD5AQbqAZ0hIXaB5Rl1iQEf7u_u9q4iqVMH9YsazOCYc FjnvM9ZY_QBxZ_pc8Pcp_GlMffv9fLUaVrVLHCx50HY6Lvpiv1BK.pUrcAkD_ointVQyuaYsengY FqtqhUbLVejhpGkhf2v9S7GWDgPOutJ.Dh.4N.5VfxcQTSO90pcipX4MARPEwcJEdJG3Qb9dbzC1 Q_mLklXFxWKiR9j_ldljYnFzBAzkQYOpJA99nYph2uPIZ8ulO1er68zxsIarhF3UfDA7TaU2lwBk qfzjwjc2xlTLBSrtXm_mSEHS5jFp0YDmOhhTZGrjEtUsBYw9ZLfqrRUSKvqiamNw6no.NhHH3rsW QjTYHVS9J4zTgoGhGLakhVl_XcrZkgBRK5OnxqAGdIXsO_PpZcLaavTKUS23D73vbzqxPyvKWksf TRbhql7uqxO4V.eQ1aLQgnO9lvth_phdoiRK1E79TFG0CiyH8kHMAm95U0uCYu3iEzF5XB5ccnSE g84H92Iv15iAQOWh83oewwRHO15MFl3OQy8859ZwxM98KIJVNAziHeMdQ89SZs2DvBLvD3eHQWGD EiD6Pi3eeBPRiPs9RgPoEX5OHGOwm53EsM55IdWXQz07Ws22FCCq911ASAXX4GOmT7i5aJN3BJH_ yTftnHm9PyxHAOdmNTEJxVxOvWZS7cGee2TA7Kc6bYJCMoUCdwtDFhTybzeOnmrkM3hW5TywcBui Gm4LGrwkH1EFQlnO5UKabc8A7Xhsiye2dtD3t_7yGuX0aiBT3k6qXJYvueyt6J.1rq2oeAotePie Kan1MjF8Nj4IlytVe578plNdvcmQY6NjOophWGHRS1SOOhtTHewtEVSunkpBs0CAc37q.fumBBaH ef2v8qTYy3QH6NaRJFcPUj_Xd_As6_WnSwJgXOL9CfzQUuq.V3HNQrQ2rPZBZxMnlSp6iXJ1qNCJ vaXYh3pK2bCG4.syWHTOdoikUAxdfx6Eismn0Cy_U4iYNYq6B3yabSOUcUOhpy9ZILzZY0SKc63E htbO01_XJ5DFrXJVqdc_Kg3Lw0X7wm.7FssLUBcchsFQ7gRd9H_xqmDd.Vq1WiffdTaRrT2L1Puw RGZzBIB8PhmOPJwxZsUyGDBdZImxbxnXDyhs_e8_K_OAtrgyJF87.C2fh4g6KeTjpVEUQCRalARq VXhKFROvfp0ayYbnMrw2Bq_ZXf.3OBdeuiVK3YZnmaY374njHgvJKOa_.1ZKUn6h9FArF.euvaUb FoIQxjaNGfno0du7UZ1yoVV9DyA1ROVotTl97Pq0g2hNX8ACh.84E545xQ.99ACpmW6kW.T0MV6H FewSBv9vqphJWkdyFSi1J40C.b2SvQoFm1yWSWciufuPNoQc0zWAMyU7ThjLxwTbPQEDaXLRJjLh Nbro9gYqLPskSyz7b7KNODwsfYOSnOvS_LZPwaarfu9NURYzQHN.zD6oe69C_or_E9F6cLpyAg07 SfXJDxNjGAKfxD1LO1PAPLFEe4XKJFo8FARMbpiSNLCVYgljBCYNJM49un1sZsLj04v4zS2Y1R0w HoJ3zTVaV4j4J_5wvAEQcYUUKXOay6HD9wfM.n.6XQHQdGk878vnHSKudnVTRcspbG9VqlFNutki WEyqPmamN1mDLDJYlvc2uh7C3fFlnHVYWr4iH5j7eeDqI2_QayQQSZsPmSHTNRXgFMu.ZKyi.ozQ XlrsYqk7fAv0r8ZkoJjS99cOfGLa8mDJIp7BYNvs228DXMNxgiZqAxGou.O3.5T8AT924DC14NC. UmL4wcievrPaLClhEgNEpakq1Tj7zMyuutoNfg5jllbgKrqzanZ4pbIpJ21GJ2iLPm.BMEEy_ZQN URAdfiiJ97WOXMEPAIF1EoQ0RXRXN6AZ24ElRuqKD1DM8GhWoOgpxcVuQaZ5MYyRdm_YHp2o- X-Sonic-MF: X-Sonic-ID: a7020784-b8fe-4358-834f-f66051fb3e31 Received: from sonic.gate.mail.ne1.yahoo.com by sonic303.consmr.mail.gq1.yahoo.com with HTTP; Sat, 31 Aug 2024 21:59:15 +0000 Received: by hermes--production-gq1-5d95dc458-c8wt4 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 7e8c252bdf6ad52a97a2e742a53b1cd5; Sat, 31 Aug 2024 21:59:12 +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: <03DB526D-6B4B-42DF-B5E2-609E174A8311@yahoo.com> Date: Sat, 31 Aug 2024 14:59:00 -0700 Cc: FreeBSD Mailing List , FreeBSD ARM List , FreeBSD Toolchain , Brooks Davis , Tomoaki AOKI 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: "mmel@freebsd.org" X-Mailer: Apple Mail (2.3776.700.51) X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.89 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.89)[-0.895]; 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.206: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-ports@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.206:from]; RCPT_COUNT_FIVE(0.00)[6] X-Rspamd-Queue-Id: 4Wx8792VWYz4rDc On Aug 31, 2024, at 13:39, Mark Millard wrote: > 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. 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. =3D=3D=3D Mark Millard marklmi at yahoo.com