From nobody Mon Aug 26 13:40:46 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 4WssJN1wTGz5Sx7r; Mon, 26 Aug 2024 13:40:52 +0000 (UTC) (envelope-from philip@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R10" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4WssJN11s2z4cYy; Mon, 26 Aug 2024 13:40:52 +0000 (UTC) (envelope-from philip@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1724679652; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=oIS4pEmLsmn0IkUOtEMsf9/1qAnXNx5wgcUcY0QRUhs=; b=tIjfAUv9cAQC/Dc4uvFXfYsogSRlO7NQrErTgFhFfPoU57Ubc8cmwJyqK4f3oxk4IT6cy1 84v2XOLMqm5GDuLLzMrFnFZZ7x2+6hjeaiDhQbEPkIWijx05DY2dZcOfsDxcO7L2sSyxe6 Yh/72b6l1Lw5aSydKnm8yfBsqnWQLysqOHaaI8da4/OvPHI/Br19bm3BT4fEDLUUdWzLf/ ZUHsy09D6C81VSoOmioIQV5ECPth0HdLmVpeIR8XARuy3gXSvXFObVo8m6eCMLJKS6gNip +fOryImqMp80Bt6UdOEIv6R+W4e3RmrvOG52MoXxuNycdECnxLnYFCDw4QQduA== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1724679652; a=rsa-sha256; cv=none; b=v9Ou6Hztd9eAFlzRoLXcWEkT812SHzCIdxCmOC5qY2Z8QdgtVXpxpCU9tlxcsuaqq7SHHY nCEjgCO/FAxBlF52CbK/LdPisIGBtlpMRwyBSf9HMseB94Ww/IxtqTspPJiSwsC7FD2aoY aAMHtix2fNfPQdEjn97tnAYy/xvvzrybeE6TruzdTEeci7iOcTpR8q6PWM5DftilG+wn6q akOfzWfd2TdgqJRtCPQWiDcr/TPfNzLnMQ3AIY0OxENd0MMontRq+hOcZsfW0nZ3yXRrzT TP1uEtDoP62BqpDb0N5DTTXtKhaRLS3BkJuFUhqDZ4PMI6oO0NyY6Bdrjg0IBA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1724679652; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=oIS4pEmLsmn0IkUOtEMsf9/1qAnXNx5wgcUcY0QRUhs=; b=GlD1IqJ/VOpxSNLKhn8YAZI+M+LXKi08luJwJFJJQT+5IquyefgEZFpi4MIRsILNL6tw5Q yf/iNdYm8FbOUj4eGo9m0M0V6fFJr35WomnwIGtt4mjYvq7Xr7t88aBwGjJlyyoFjC1kTl BNuUGFVeuiOG9KtCVQcZSF+vWF23w/+AtNaNuNHUN02LY2nToW23EQXPwBpk/kfLrVhuJZ yTOKLjiItye4LhQGCX/qe6z4uqyfOTqPqgXw9hKpcjqHTWhrNzOO2XRqHCxY8LRSmEP0dp GV4jtDeoJJ7BgHNIDZIYMgJNT9ZEvZcySh8PnjEAxlu9NA1IL4ZMjB9NwgI15A== Received: from fauth1-smtp.messagingengine.com (fauth1-smtp.messagingengine.com [103.168.172.200]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: philip/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4WssJN0NDBz14jt; Mon, 26 Aug 2024 13:40:52 +0000 (UTC) (envelope-from philip@freebsd.org) Received: from phl-compute-04.internal (phl-compute-04.nyi.internal [10.202.2.44]) by mailfauth.nyi.internal (Postfix) with ESMTP id A7AF0120006D; Mon, 26 Aug 2024 09:40:49 -0400 (EDT) Received: from phl-mailfrontend-01 ([10.202.2.162]) by phl-compute-04.internal (MEProxy); Mon, 26 Aug 2024 09:40:49 -0400 X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeftddruddvkedgieeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgfnhhsuhgsshgtrhhisggvpdfu rfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnh htshculddquddttddmnecujfgurhephffvvefufffokfgjfhggtgesthdtmhdtredttden ucfhrhhomheprfhhihhlihhpucfrrggvphhsuceophhhihhlihhpsehfrhgvvggsshgurd horhhgqeenucggtffrrghtthgvrhhnpefggfefieegtedtledtgfevtdfftdegvdehueei teehteefieefveevtedvvdekgeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmh epmhgrihhlfhhrohhmpehphhhilhhiphdomhgvshhmthhprghuthhhphgvrhhsohhnrghl ihhthidqudduieeivdeivdegkedqvdefhedukedttdekqdhphhhilhhipheppehfrhgvvg gsshgurdhorhhgsehtrhhouhgslhgvrdhishdpnhgspghrtghpthhtohepfedpmhhouggv pehsmhhtphhouhhtpdhrtghpthhtohepmhgrrhhklhhmiheshigrhhhoohdrtghomhdprh gtphhtthhopehfrhgvvggsshguqdgrrhhmsehfrhgvvggsshgurdhorhhgpdhrtghpthht ohepfhhrvggvsghsugdqphhorhhtshesfhhrvggvsghsugdrohhrgh X-ME-Proxy: Feedback-ID: ia691475d:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 26 Aug 2024 09:40:48 -0400 (EDT) From: Philip Paeps To: Mark Millard Cc: FreeBSD ARM List , FreeBSD Mailing List Subject: Re: ampere2 did not even try to build main-armv7-default: it is only trying to build main-arm64-default Date: Mon, 26 Aug 2024 21:40:46 +0800 X-Mailer: MailMate (1.14r6059) Message-ID: <0FD5A72E-BFFF-422C-B38F-7EDFB832FAFB@freebsd.org> In-Reply-To: <90DDBA5B-1D0C-402F-88F5-704DD7D439B9@freebsd.org> References: <90DDBA5B-1D0C-402F-88F5-704DD7D439B9@freebsd.org> 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 Content-Type: text/plain; format=flowed On 2024-08-25 14:01:09 (+0800), Philip Paeps wrote: > On 2024-08-24 14:34:01 (+0800), Mark Millard wrote: >> On Aug 19, 2024, at 20:17, Mark Millard wrote: >>> main-arm64-default p60a177caf143_s7a8d05ba19b >>> finished its last package build at: Aug 19 17:50:28 UTC 2024, >>> building 34197 of 35762 Queued >>> >>> The next build to start on ampere2 was: >>> >>> main-arm64-default p3efa6621722c_s4132c4be4c0 >>> starting at: 20 Aug 2024 01:13:06 GMT, >>> 18092 Queued. >>> >>> I do not see any evidence of it attempting a >>> main-armv7-default build. >>> >>> So there is still no evidence being gathered for if the >>> hangup fix in the world (jail) code is sufficient to >>> lead to a from-scratch poudriere "bulk -a" running to >>> completion for armv7. >>> >> >> It looks like in the next day or two, p3efa6621722c_s4132c4be4c0 >> of main-arm64-default on ampere2 will finish its "bulk -a" build. >> >> Question: Will main-armv7-default be the next "bulk -a" attempted >> by ampere2 so that there will finally be an updated distribution >> of packages for main-armv7-default (presuming that build >> completes)? > > I've been spread very thin. I'll take a look at what state the > ampereXen are in. I haven't looked at them in several weeks. They're > on my list for the ongoing cluster dogfood refresh, but I've been > working in other areas of the cluster for a couple of weeks. > > Thanks for the nudge. It looks like package building for arm architectures is not in great shape. I've put this higher on my list. I hope to get to it in the morning. Philip From nobody Mon Aug 26 17:18:41 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 4Wsy7n6V5sz5THc0 for ; Mon, 26 Aug 2024 17:18:45 +0000 (UTC) (envelope-from fred@thegalacticzoo.com) Received: from nmtao102.oxsus-vadesecure.net (mta-132a.oxsus-vadesecure.net [135.148.117.230]) (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 4Wsy7m6bkyz41bn for ; Mon, 26 Aug 2024 17:18:44 +0000 (UTC) (envelope-from fred@thegalacticzoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=webcom.xion.oxcs.net header.s=mail1 header.b=bRBdIUr6; dmarc=pass (policy=quarantine) header.from=thegalacticzoo.com; spf=pass (mx1.freebsd.org: domain of fred@thegalacticzoo.com designates 135.148.117.230 as permitted sender) smtp.mailfrom=fred@thegalacticzoo.com; arc=pass ("oxsus-vadesecure.net:s=arc-202309-rsa2048:i=1") ARC-Seal: i=1; a=rsa-sha256; d=oxsus-vadesecure.net; s=arc-202309-rsa2048; t=1724692723; cv=none; b=HplX4sHV1nrnLSIA2/RnUOMMsy9y8UNZbTd+p1ZYkLJ61pCzlRUK3wmRQSzVDxgxZkThwH939XUlGqtN9PZgg2pbfPuFAUqnzNfJ9MqpXD5MBOv1tSbaQKMCIJ8XySlnK3hj5wBkC9o2wIKXOWO+q7kQYGYLjsiaEGBhNao1R1N0Tz0Gu6oQoMHygsWcpvI9Qb7MHohquDN60ryT61h8koqPgyUjCuyiJ1a2gEdl/aJqnGvpVeBdohbnjz7gM79pP7GJMBc4g47WgnNbzWp2bhgu8aykY0DZRGazLlqGv6e4c62G3dr5Gr6HK3nMX1b7OTnWxyqlJqK8gcDR/A1ToQ== ARC-Message-Signature: i=1; a=rsa-sha256; d=oxsus-vadesecure.net; s=arc-202309-rsa2048; t=1724692723; c=relaxed/relaxed; h=from:reply-to:subject:date:to:cc:resent-date:resent-from:resent-to:resent-cc:in-reply-to:references:list-id:list-help:list-unsubscribe:list-unsubscribe-post:list-subscribe:list-post:list-owner:list-archive; bh=ExQxcsiiUTxvZO2ehosEb7Hd7kwYiOMDkd/Do5Oey90=; b=UFIOKCuPUvTO8PsYMoTG69hmmGEWnjzTB2x0Z9W0DL8uaLwjF0HmlxsXPyRSRTkuTjpnIPw+6bxKE4h7aPO+ZClCC+NYk2pqAYZQQcxeLKyJ+Hy9AUHDwkESVR2jYOjMguysqcv2tMiI3uLCaid9DkqTxdjKUX2AyJRNPGfxbSfDX2+4S8pZGWH/L2rspf8mn5MBKpJ6vhQUTjSAz3sVOH7WgVKb/nJOJ5XlAMPDFfG9dL8skbEB9Nh8DUwWNGm+mHNS2ctK71B1aMnTAtJnPKYLUofDA0QbQOvIq+T6Tcw2O/QYlaUV37U3PnQmSK7ahdKl7Nlio53joDURft/wlw== ARC-Authentication-Results: i=1; DKIM-Signature: v=1; a=rsa-sha256; bh=ExQxcsiiUTxvZO2ehosEb7Hd7kwYiOMDkd/Do5 Oey90=; c=relaxed/relaxed; d=webcom.xion.oxcs.net; h=from:reply-to: subject:date:to:cc:resent-date:resent-from:resent-to:resent-cc: in-reply-to:references:list-id:list-help:list-unsubscribe: list-unsubscribe-post:list-subscribe:list-post:list-owner:list-archive; q=dns/txt; s=mail1; t=1724692723; x=1725297523; b=bRBdIUr6Qejrbf4ReKPKE MdMXqC8ywUMq07nImk6lmIfqGYExKVdW+DTkADYDm3pzMXMWIIX8+WX+QlbS+NRSk7eaEG3 JXnObNgUXBnRVtR/X7TiHLvTdzX3i4GBVaLjwQvAFKvjme8PjUvF+AqxX7IX+kfuBvtNmUQ dz1rK0ONiW+ruBhbD+KnwnNBVZt9f4zfuf8zFQah5Zk6Hv13ayGZFMjXtiBCaDlx/uaTtT5 HGkz9+dtE4mqa4ltDVPcUO077dh983A2IueSMvNVhg6Rjv8UOo2HharvMMOUn2dI/5MFg6I dfi0uYFpzYnkuP/6L58rfgICZJCEcalxxQXFg== Received: from proxy-8.proxy.cloudus.ewr.xion.oxcs.net ([172.56.168.253]) by oxsus1nmtao02p.internal.vadesecure.com with ngmta id 9ddb81dc-17ef56e4dba131ac; Mon, 26 Aug 2024 17:18:43 +0000 Content-Type: multipart/alternative; boundary="------------7VBsJi6dsDME2aom9WCw3PqI" Message-ID: <18663703-ec53-4d87-b035-1eadd5f803d2@thegalacticzoo.com> Date: Mon, 26 Aug 2024 13:18:41 -0400 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 User-Agent: Mozilla Thunderbird Content-Language: en-US To: freebsd-arm@freebsd.org From: Fred Finster Subject: Audio out from TV speakers using VCHIQ on Raspberry Pi 4B, 400, or 3B , 3B+ [SOLVED] Organization: Kliktel.biz X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.88 / 15.00]; ARC_ALLOW(-1.00)[oxsus-vadesecure.net:s=arc-202309-rsa2048:i=1]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.99)[-0.987]; DMARC_POLICY_ALLOW(-0.50)[thegalacticzoo.com,quarantine]; R_SPF_ALLOW(-0.20)[+ip4:135.148.117.228/30]; R_DKIM_ALLOW(-0.20)[webcom.xion.oxcs.net:s=mail1]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; ONCE_RECEIVED(0.10)[]; XM_UA_NO_VERSION(0.01)[]; RCVD_COUNT_ONE(0.00)[1]; ASN(0.00)[asn:16276, ipnet:135.148.0.0/17, country:FR]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCPT_COUNT_ONE(0.00)[1]; HAS_ORG_HEADER(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[135.148.117.230:from]; TO_DN_NONE(0.00)[]; RCVD_TLS_LAST(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DKIM_TRACE(0.00)[webcom.xion.oxcs.net:+] X-Rspamd-Queue-Id: 4Wsy7m6bkyz41bn This is a multi-part message in MIME format. --------------7VBsJi6dsDME2aom9WCw3PqI Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Here is my solution for patching FreeBSD kernel source code and also patching GhostBSD kernel source code with exact same 3 patches from Marcos Devesas-Campos My review is here D43399 review.freebsd.org https://reviews.freebsd.org/D37878 https://reviews.freebsd.org/D37879 https://reviews.freebsd.org/D36431 https://reviews.freebsd.org/D43399 I am looking for confirmation from your testing that these patches do work or DO NOT WORK.   They did work for me on both standard FREEBSD kernel source code at  /usr//src  and also on GhostBSD kernel source code at my selected directory location of /usr/ghost14/src Questons:  Does the audio come out your HDMI Television speakers?  YES, NO, SOMETIMES ?? Why? Can you change from HDMI audio only, to analog 3.5MM headphones, or both at the sametime? Does using these patch files, work also on the Raspberry Pi 3B and Raspberry 3B+,  Raspberry Pi 400 keyboard model SBC, Raspberry Pi 4 compute module. Anybody get a BlueTooth USB dongle working on Arm64 Raspberry Pi hardware or other Arm64 SBC? Raspberry Pi 5 users will have to test their different HDMI audio setup (not VCHIQ internal subsystem in the BCM2712 SOC) and let others know about their findings of playing Videos with sound coming out the HDMI Television speakers or out Bluetooth connected audio (I do not know if Bluetooth is supported on Raspberry Pi 5 or you have to add a USB dongle). https://forums.freebsd.org/threads/raspberry-pi-5-status.91406/page-3 Here is RPI 5 Status Forums page https://ghostbsd-arm64.blogspot.com  search on word  HDMI or Audio to find the relevant blog post. Review D43399 has instructions and URL links to other bits and pieces.  I posted a detailed write up on a Fxxxxxx image where I wrote a reply to Chinese developer.] https://reviews.freebsd.org/D43399 https://reviews.freebsd.org/F75131370   Here is an explicit write up how to download and use 3 patches for enabling HDMI Audio through the VCHIQ sub system inside the SOC BCM2711. ~~~~~~~~~ sysctl dev.pcm.0.dest sysctl dev.pcm.0.dest=0   plays audio on analog 3.5mm jack and HDMI Audio at the same time. Marcos FreeBSD-arm maillist post on Raspberry Pi VCHIQ audio sound usage. From: Marco Devesas Campos Date: Tue, 06 Sep 2022 11:23:08 UTC Hi On 7 Sep 2022, at 06:04, Fred Finster wrote: VCHIQ sound on Raspi4B HDMI audio. Which DTB to include on config.txt file, Any other missing pieces? stock confit.txt and dtb-s. dmesg should then show vchiq0: mem 0x7e00b840-0x7e00b87b irq 72 on simplebus0 vchiq: local ver 8 (min 3), remote ver 8. pcm0: on vchiq0 and cat /dev/random > /dev/dsp should play static If nothing’s playing, flipping the sysctl dev.pcm.0.dest through * 0: both hdmi and headphones * 1: headphones * 2: hdmi usually brings the audio back to life. Best, Marco * Wish you a SOUND fun time using this VCHIQ Audio patch for FreeBSD on the Raspberry Pi ** ~~~~~~~~~ ps.  Anybody test and verify drivers for the extra serial ports on the raspberry Pi 4B hardware. Uart0, Uart1 ttys work, but Uart2, Uart3, Uart4, Uart5  do not work and are not tested.  How about testing the I2C and other serial interfaces (i2S??)? on the Raspberry Pi 4B hardware ( 3B, 3B+ hardware too) Slowly but surely progress in using FreeBSD on Arm64 hardware is improving.  Thank you FreeBSD Foundation and developers. pss.  Anybody working on porting the OpenBSD and/or NetBSD device driver for the cy445 internal wifi subsystem on the Raspberry Pi 4B, 400 hardware SBC?  I have looked at the OpenBSD bwfm driver source code.  The realtek chipset in a USB dongle does work for internet connectivity via wifi from raspberry pi SBCs.  8188eu (TP-Link mfg), 8192cu (Edimax mfg) psss. Once HDMI Audio VCHIQ is working, would be nice to compile or download ORCA screen reader and make this operational on the Raspberry Pi hardware for Low Vision users to have an inexpensive desktop computer connected to a HDMI television with working TV speakers operational. Best of luck in your use of FreeBSD Arm64 on other existing SBC hardware.  I was really impressed with all the software that just worked OOTB (out of the box) with a simple  pkg search  and pkg install geany falkon xfce xfce4-goodies for Arm64.  We all benefit by sharing information , even when not on a High Powered Arm64 Server. Yes,  I ran Poudriere 24hours a day (for 30 days) building packages on my Raspberry Pi 4B, 8Gigs dram, 1 Terabyte USB SSD. Ugreen Case with realtek interface chip inside to connect USB to a M.2 NVME stick inside a metal case.  Poudriere did build the packages and the NGINX web server served the packages to the world using a NO-IP.com URL for a dynamic-IP connection at my home. ( I recently moved so am not setup again with the Raspberry Pi online and not working presently http://ghostbsdarm64.hopto.org) Leaving here as a future reference. psss.   What is your JTAG debug setup for ddb or gdb with your Arm64 hardware?.  I was looking at BMP Black Magic Probe hardware, but looks like it support 32 bit ARM debug and not 64 bit ARM debug.  The other JTAG hardware with 1.8 - 3.3V ttl serial interface is the "JEFF Probe" by FLIRC.  What do you suggest as a good JTAG interface tool?  What works for you? https://forums.freebsd.org/threads/debugging-arm64-booting-of-freebsd-ghostbsd-kernel-for-raspberry-pi-4-what-tool-do-you-use-any-jtag-hardware-kernel-debug.90436/#post-623625 Thank you for reading.  Yes, I asked many related questions.  I hope you answer a few questions over on a post at https://forums.freebsd.org Fred Finster (temp phone 503-949-oh-seven-six-six) -- Fred Finster 971-718-9144 https://ghostbsd-arm64.blogspot.com --------------7VBsJi6dsDME2aom9WCw3PqI Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit

Here is my solution for patching FreeBSD kernel source code and also patching GhostBSD kernel source code with exact same 3 patches from Marcos Devesas-Campos  

My review is here D43399 review.freebsd.org

https://reviews.freebsd.org/D37878

https://reviews.freebsd.org/D37879

https://reviews.freebsd.org/D36431

https://reviews.freebsd.org/D43399


I am looking for confirmation from your testing that these patches do work or DO NOT WORK.   They did work for me on both standard FREEBSD kernel source code at  /usr//src  and also on GhostBSD kernel source code at my selected directory location of /usr/ghost14/src 

Questons:  Does the audio come out your HDMI Television speakers?  YES, NO, SOMETIMES ?? Why?

Can you change from HDMI audio only, to analog 3.5MM headphones,  or both at the sametime?

Does using these patch files, work also on the Raspberry Pi 3B and Raspberry 3B+,  Raspberry Pi 400 keyboard model SBC, Raspberry Pi 4 compute module.

Anybody get a BlueTooth USB dongle working on Arm64 Raspberry Pi hardware or other Arm64 SBC?


Raspberry Pi 5 users will have to test their different HDMI audio setup (not VCHIQ internal subsystem in the BCM2712 SOC) and let others know about their findings of playing Videos with sound coming out the HDMI Television speakers or out Bluetooth connected audio (I do not know if Bluetooth is supported on Raspberry Pi 5 or you have to add a USB dongle).

https://forums.freebsd.org/threads/raspberry-pi-5-status.91406/page-3   Here is RPI 5 Status Forums page

https://ghostbsd-arm64.blogspot.com  search on word  HDMI or Audio to find the relevant blog post.

Review D43399 has instructions and URL links to other bits and pieces.  I posted a detailed write up on a Fxxxxxx image where I wrote a reply to Chinese developer.]

https://reviews.freebsd.org/D43399

https://reviews.freebsd.org/F75131370   Here is an explicit write up how to download and use 3 patches for enabling HDMI Audio through the VCHIQ sub system inside the SOC BCM2711. 

~~~~~~~~~

sysctl dev.pcm.0.dest

sysctl dev.pcm.0.dest=0   plays audio on analog 3.5mm jack and HDMI Audio at the same time.

Marcos FreeBSD-arm maillist post on Raspberry Pi VCHIQ audio sound usage.

From: Marco Devesas Campos <devesas.campos_at_gmail.com>
Date: Tue, 06 Sep 2022 11:23:08 UTC

Hi

On 7 Sep 2022, at 06:04, Fred Finster <fred@thegalacticzoo.com> wrote:

VCHIQ sound on Raspi4B HDMI audio. Which DTB to include on config.txt file, Any other missing pieces?

stock confit.txt and dtb-s.

dmesg should then show

vchiq0: <BCM2835 VCHIQ> mem 0x7e00b840-0x7e00b87b irq 72 on simplebus0
vchiq: local ver 8 (min 3), remote ver 8.
pcm0: <VCHIQ audio> on vchiq0

and

cat /dev/random > /dev/dsp

should play static

If nothing’s playing, flipping the sysctl dev.pcm.0.dest through

  • 0: both hdmi and headphones
  • 1: headphones
  • 2: hdmi

usually brings the audio back to life.

Best,
Marco

  • Wish you a SOUND fun time using this VCHIQ Audio patch for FreeBSD on the Raspberry Pi **

~~~~~~~~~

ps.  Anybody test and verify drivers for the extra serial ports on the raspberry Pi 4B hardware. Uart0, Uart1 ttys work, but Uart2, Uart3, Uart4, Uart5  do not work and are not tested.  How about testing the I2C and other serial interfaces (i2S??)? on the Raspberry Pi 4B hardware ( 3B, 3B+ hardware too)

Slowly but surely progress in using FreeBSD on Arm64 hardware is improving.  Thank you FreeBSD Foundation and developers.


pss.  Anybody working on porting the OpenBSD and/or NetBSD device driver for the cy445 internal wifi subsystem on the Raspberry Pi 4B, 400 hardware SBC?  I have looked at the OpenBSD bwfm driver source code.  The realtek chipset in a USB dongle does work for internet connectivity via wifi from raspberry pi SBCs.  8188eu (TP-Link mfg), 8192cu (Edimax mfg)

psss. Once HDMI Audio VCHIQ is working, would be nice to compile or download ORCA screen reader and make this operational on the Raspberry Pi hardware for Low Vision users to have an inexpensive desktop computer connected to a HDMI television with working TV speakers operational.

Best of luck in your use of FreeBSD Arm64 on other existing SBC hardware.  I was really impressed with all the software that just worked OOTB (out of the box) with a simple  pkg search  and pkg install geany falkon xfce xfce4-goodies for Arm64.  We all benefit by sharing information , even when not on a High Powered Arm64 Server.

Yes,  I ran Poudriere 24hours a day (for 30 days) building packages on my Raspberry Pi 4B, 8Gigs dram, 1 Terabyte USB SSD.  Ugreen Case with realtek interface chip inside to connect USB to a M.2 NVME stick inside a metal case.  Poudriere did build the packages and the NGINX web server served the packages to the world using a NO-IP.com URL for a dynamic-IP connection at my home. ( I recently moved so am not setup again with the Raspberry Pi online and not working presently  http://ghostbsdarm64.hopto.org)  Leaving here as a future reference.


psss.   What is your JTAG debug setup for ddb or gdb with your Arm64 hardware?.  I was looking at BMP Black Magic Probe hardware, but looks like it support 32 bit ARM debug and not 64 bit ARM debug.  The other JTAG hardware with 1.8 - 3.3V ttl serial interface is the "JEFF Probe" by FLIRC.  What do you suggest as a good JTAG interface tool?  What works for you?

https://forums.freebsd.org/threads/debugging-arm64-booting-of-freebsd-ghostbsd-kernel-for-raspberry-pi-4-what-tool-do-you-use-any-jtag-hardware-kernel-debug.90436/#post-623625


Thank you for reading.  Yes, I asked many related questions.  I hope you answer a few questions over on a post at  https://forums.freebsd.org

Fred Finster (temp phone 503-949-oh-seven-six-six)


-- 
Fred Finster  971-718-9144
https://ghostbsd-arm64.blogspot.com
--------------7VBsJi6dsDME2aom9WCw3PqI-- From nobody Tue Aug 27 02:34:18 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 4WtBT45Q7Pz5TrSR for ; Tue, 27 Aug 2024 02:34:32 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic306-21.consmr.mail.gq1.yahoo.com (sonic306-21.consmr.mail.gq1.yahoo.com [98.137.68.84]) (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 4WtBT41W7dz43bq for ; Tue, 27 Aug 2024 02:34:32 +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=1724726070; bh=iCZDCIC5O9pZkkqu64ACa0N8esuIMFvTS3Py+4eLA4g=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=IvNbGdPtcLcuB3t+PSVu3Vi13WDMBErTe+Z0OhsKtfN7MY07PB8TBTxiIibS8Vjr6kChtTRYUs8qGwDzwIyXuj4z4stNJkymhVH4XNGux2dh1romt2tm7Z+gcAXdAgcRpEqGYK3+5aoBcARBW1iMqzbiLYJjKMvIPfCTGImyQhdXILcHSFmG5AWqwXLQv+h7NR2CkrZ4pm4Ym9vn0+jrUnxMQenj8sgtMN/qEtglw5etmx8N8veKCbzost25JBavWdTafQB6kgmSSOM9YkqDeDwFy8CrhwPaQLOIDvR8inCUzbLR45RxtfTVDBek82/eHvOzXnr5m6UJYipwP6t2Qg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1724726070; bh=EkvRABTjoCNvmSpB2iU3fJJGs9J4Lss031P0ZsM+5+9=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=SqFdDg6qCl/grmYY2wqbFZYK4gcuYBxoylwO9Cjbf8rmeMWCtleDwt0QPLDV0k6/OKrmkrHidd5P7642Xj658rQmjuqSVVy165zq2mE4yWqNHPKS3Br9ZodWOs69I2Kio6c0x7yp3FejkUJzjHgcyFQM/bDL1rF8a2C5CTNfOqWj0sk5DJkXtgTthIQv2z3gR4OF/y7nfmtSRwo4nEdnD97ucX3BajIHltnWhO8h+qCKsTae7Z6FHBVE/+NnRvPfL3DpwJ6rB45sOSi7UTUp0WEiOaaAKFNVCAUzWCJEYqvWpM7ADrMYT/wYnsvjeEZwmuKti+FMl/xY/RRV9UHBqw== X-YMail-OSG: .RIb_x0VM1m_u_uPlnupLdIHJEAvV3ZV3JbhKRZQXZugzJo4kgZZAprS95miBFy RM51Sa2jK4_5iZlIbT8b9GymTKjh71WAd1.SNSGbB9UzE1H8OkxHeg8Bw35gKgHGhFLgLep52Iwc x8a3AHZZ7d_cdOMCh7lYn89vGD1ShEg3EIY0VGoKy4IQRFL8AloYU_EZTEUiIwT6W56SqjxjHYS6 S..GMO3IkwfZZEF._kolSkL28YxZpmTMIdn6bjS59SDOOPBAoFdcfJoRihzHM5VcWSGYhiLUxOM1 moM4rUYyql8YDdTNOowF6IhasODB5MqMs3hh_ov7k7Bv6xx9611D3.ZC2f7ccYj.kTqFogoXqe.W SZ.ZxcgNQWYWM.Tqn5tqrNB.AsLQ9JH9rw3QUuaFlEt7ScpD.pJTNZfaeaMGkfTaOyOXQikuldur 0KyFqR24HwrTQ4BHvKz4uDW_5n9zE4Jc.nf3Yc3pt3bqGXI5OEmv6J_n8Rx47MPfbmXV_y5fug0z .ENk1rexwpxn0hQ4h0zCYWKNV6TDScKCEn3l16xjR72_btkUdMK0apyUdHJc72dLJJ0Hv95hud3U 8WvklGleYltktcro5Lw9XPvCdNkyjolJ4_VY5CDMiXr85paZWOdiTzt_aZ7NwgyjZ013zY9jb9jw 6Qzy4IoLPVgLfTux3bCrwi1SdkeopdEo07kjz0EV4ySKaUsabvRCU2quOY2HTpyWuEmTMYlXdp21 6LJIvw7e5NktAG0voBuJmPStr6.hJ05X66EqLXKSfMQpW75JRZAB.CUWCfV_y6Ju9D3VkSbZhpfF ozRDKWAx562FdZaLbQ.Nuu9zw3WWQN4Pr_I.oXdnzcOBZEXJm5JLVbJ7jkBJc4S9K0jooOXiIQMd wFxODDAw9jAYViUQLBhpsTU_Y5NH2YVBpS9ECBV9JwIKPKgjDBzu5Z7ghh7Ow22vpZMd_gtC1rsc h3ZH6uEJQwIwXOw9h5YT9hCbap_KwwFJrc6E7xPERGCqWRgBU198w9FMfnYldBK4FnPLCdHE_6d1 4qplkebV9nbWCKm385W4eDDXpBdDAMHzCm1fotCD5vJcRQ3wykZ2XjIDfRzp8mYnGgIrHnHQr218 Q7nyRMh4GP80M6DzUDxamXs04gPimI2F8QmUnskGL5Hi6RIrStvfhYH1MKAB8zG1M_Q_FzK1C504 wqeJ824r2KfqABegT3lvmExibEjyyGtUh.67RfQ3oUYuEkeiffUV82wu.mKsL4PDSATDbVoTjdRe VZ2vURfuPFjJvI91ne3DxIb.BKeNwWd_qp0FcCpu5qlx.WvAl_1rC2eyxr2e0jJOiTrHce_Wt9j1 .zNhqRMU0EA9HTeLfjQG.zr2bWOzNL4O7vj9GIvuDIAlVP1CNCFkMrmo7pVlHYS2EtDnYfZCgr7r Vc4VanDs_Ev4I.o_j0RN1Iy4l7sLxfuDEGs4YPWQicfvPN1mb4Ni94dtbRt_EzVFlpYgBZkO27jA OGCSzZrPKs9adQuBB_oep1mPjuiEc_1EtvxXdXtDBrzAly5gLydl4SypuJfulPnrG0DOs0D.mzdh DVuEYEgCRRoD8OWZIHOEu8N5nDAVIplbxGq0wYOL9IsEohX4qqBtZ2nu1wijYaoaaVadOipUlbgy QaXTRHr4.1_0U6jINaHbmw1YU_rC_I95mdZPSxMr1pDJVcF5ZvoA_OizuTf96Qrt4lPO.7I7Ki0z GndKHXC0veqKB18AfVsKEZhVg.UffqHiyqW0vEkNn23n1FFH7Tbg318YvXN6malL8qBCMmDTnfcI krSrFlyuMoersOTmR.YQc6XUaA6bqH4zul2eAY4CGKtdWEbimF61WFRHtz63_OlYVj_VHgmNN6ut buUJMJSi7_L2O1D2k6uGECetIsakFxVPQ5Gws4Ru8nEA.9YIz6pMrHm5piYQblqyazL9tjLYMuUL RzBC2GZdjH.G3gDRWZS7vw_0iqsW9TCWLlwjt6f.Wupu9k6StWoj05qQzfwO68suJK2h5Kf.iMQp JNxlHDvto9WwkU04qn4XKGtpyRGX38tNfOdjbSBxKWZKiHpFP6HjDkzXmALlLc8Q5ydIzEEhuWta fhsFM0bSHI7mBvz2IUq0OhEXYrycNOg50DOxNSeZUmT0RJ.WoZHcN.c6KeJms4O8eXEzu3W0qKO9 KLFRr6EyYM2TgPwY5e25ADF_boD66A4BkUukvq3hmVVHv.XcKMqYjtGLcPp4qtPnGjd12fg1czaQ .Fr7voU4LeoIvFqZtprfbgLqUPCHC5VCijvWnfA7j_71Z57xHCUaAGdg9BvLp7jDp.ENovlXMnDl 91z7s22Zwnd0G0JYE X-Sonic-MF: X-Sonic-ID: f339cb89-0e7f-41b0-b4a9-8ca558a59e71 Received: from sonic.gate.mail.ne1.yahoo.com by sonic306.consmr.mail.gq1.yahoo.com with HTTP; Tue, 27 Aug 2024 02:34:30 +0000 Received: by hermes--production-gq1-5d95dc458-m8nfd (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID ea58c71883dd445d2515d36baaada4b9; Tue, 27 Aug 2024 02:34:29 +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: ampere2 did not even try to build main-armv7-default: it is only trying to build main-arm64-default From: Mark Millard In-Reply-To: <0FD5A72E-BFFF-422C-B38F-7EDFB832FAFB@freebsd.org> Date: Mon, 26 Aug 2024 19:34:18 -0700 Cc: FreeBSD ARM List , FreeBSD Mailing List Content-Transfer-Encoding: quoted-printable Message-Id: References: <90DDBA5B-1D0C-402F-88F5-704DD7D439B9@freebsd.org> <0FD5A72E-BFFF-422C-B38F-7EDFB832FAFB@freebsd.org> To: Philip Paeps 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: 4WtBT41W7dz43bq On Aug 26, 2024, at 06:40, Philip Paeps wrote: > On 2024-08-25 14:01:09 (+0800), Philip Paeps wrote: >> On 2024-08-24 14:34:01 (+0800), Mark Millard wrote: >>> On Aug 19, 2024, at 20:17, Mark Millard wrote: >>>> main-arm64-default p60a177caf143_s7a8d05ba19b >>>> finished its last package build at: Aug 19 17:50:28 UTC 2024, >>>> building 34197 of 35762 Queued >>>>=20 >>>> The next build to start on ampere2 was: >>>>=20 >>>> main-arm64-default p3efa6621722c_s4132c4be4c0 >>>> starting at: 20 Aug 2024 01:13:06 GMT, >>>> 18092 Queued. >>>>=20 >>>> I do not see any evidence of it attempting a >>>> main-armv7-default build. >>>>=20 >>>> So there is still no evidence being gathered for if the >>>> hangup fix in the world (jail) code is sufficient to >>>> lead to a from-scratch poudriere "bulk -a" running to >>>> completion for armv7. >>>>=20 >>>=20 >>> It looks like in the next day or two, p3efa6621722c_s4132c4be4c0 >>> of main-arm64-default on ampere2 will finish its "bulk -a" build. >>>=20 >>> Question: Will main-armv7-default be the next "bulk -a" attempted >>> by ampere2 so that there will finally be an updated distribution >>> of packages for main-armv7-default (presuming that build >>> completes)? >>=20 >> I've been spread very thin. I'll take a look at what state the = ampereXen are in. I haven't looked at them in several weeks. They're = on my list for the ongoing cluster dogfood refresh, but I've been = working in other areas of the cluster for a couple of weeks. >>=20 >> Thanks for the nudge. >=20 > It looks like package building for arm architectures is not in great = shape. I've put this higher on my list. I hope to get to it in the = morning. >=20 main-arm64-default on ampere2 has started building as of Tue, 27 Aug = 2024 01:58:37 GMT. 14609 were queued. So, unless that is stopped, it will likely be days before = main-armv7-default would be started. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Thu Aug 29 07:48:00 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 4WvYLK35gSz5MTJf for ; Thu, 29 Aug 2024 07:48:25 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic309-22.consmr.mail.gq1.yahoo.com (sonic309-22.consmr.mail.gq1.yahoo.com [98.137.65.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 4WvYLJ4ZWGz43gk for ; Thu, 29 Aug 2024 07:48:24 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=Zxxz3QfS; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.148 as permitted sender) smtp.mailfrom=marklmi@yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1724917697; bh=TV/I43VQ8eu6d2A1GBhuew+wt0Fff2w0hMTicC2ayh0=; h=From:Subject:Date:Cc:To:References:From:Subject:Reply-To; b=Zxxz3QfSsdS8D+S+h9euprRrxZeOcCAgAvWEgQc+riy6UYrNGeLjMqEE+1WHh9n/fr5JqPpWXM2NRY0Is3dCpH316kzf+qnmzpXBrIz8wtSHv29huin1U4SV/Us0OCdrNUhbazgJlwC4Nq5CS98os/akPbMuegWJaGqODSOydEZoXTC6KBn0NLGRaLEAo+kER30/4S48qYmAM512bFhCuYq3IRCYk5/V17R+kM0mC1+uj+lqsebGeS6NuTY2jAvOJwVDpkOiusSddzH7DngEFKFY24Ib1BUislAJ/SSuAuKu1aYhFYMlai0BYpHccJUPQtx4NrHpueOkiuFq/UJgAQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1724917697; bh=d3VmVfuDu0waUN1Sy0sROACNR/5d6t7+dg5h3rFAUeE=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=C3IdBOZeirKJNfg8oaAVlhN8bPPnNmF4xjfnrEyh7cK0YDJMXEyffTN4gLkQbBCqIlbvdi76ZgIfA6IdrkMoVljbh4P8FaUK6HWla4HOqL8B966Q/iz5+azhS7Qe2jnDPsRNTRbEFdxEc9qaLFQBq31QIlgRM6ypkezM5NPSZ/VDW4uMcG7EDn3TJ5vfVDMWjFitk4m4ZeAP0EKq77dRcr4OMJmLRob/lQgM4JechcQuqnLjxyZW2yH6OcD/SYeqfRZSHEkdOzVPgODYZY276BxfbKNqzxdGh3txxSvA1GIEQFPOHP6q1e/IQqzV3itxzYpzX6X3326+U4tm++FPJA== X-YMail-OSG: YV7iqWoVM1kO.HcKlgkZbg1usf473cIfJCETZKiKxy_JsFhA5aobKBDmk01NlNx mlviKhSqz3pUbcQl6VSdxvISnzcFb8Fe_75IN_XaZa48TaMcjNdwGAarnhMWZ0ksHbLPFzEX0oZl yXQUjkwCGB5vNz_yafeXRM90b7UcDr5mNK.URuSEUY6MRgHI0EaLbbwuM3NE4cMBRFuoC.BANqIx j8_BN5oQ5aPX.k1dglctefdSnSprRQUFvCnw1GxCxXnhQV2YVbmlXPZcW015fS4g10hyjglKSobm o51R1x0NDt7xgUmQYCEh6mGdIlFFDn2hmPXyyahKMQujq.k32YARNV6snTZAJWAWgi1E44oJifht RSu5xiTIXOV8rWt_I__auRt7M7.a5Wsa.dRusoSaUSimudBBGpUkeZNLPCnY9Qs3rI3NPXcoipmw gNmRNdtjMptZGQ_uc4o58b6YVI454zG1WvYtiM6aTo7Vwg0wY7Xz1wfz2wOMs9MpTgvMrs8Yxfom wSrmtIHJjzlfQeiC6QeeUOoI4YtMoXblTBMd4Uq9frLfmztzn2e0jbmJpXaLhhboML.ZP7.Y2NZh H5inRAFrEkx4T0pl_G65lzhvvX5_9g8mKZIk.TdyneIJupI.tPj2Cl0hmJjR5ENriNZsuSRJ3jLA TNz2inWRpOonkJYzh3moym_n.8_Vv8MX1a9lCPrPuNOmBZ253VbJWmUnFD7619AwDDiGNSmnBdHf 7NtiAQM6y75gvYmGNcnlLyHVih8GPSOaUCPgQO_EJP8u9yjt2cKA8cVlgNWIchn5M31PfnT.2G4U cQn.ZsTaU8CL84lRAGxGq5va4NU2dpnsjd0CA6algya2NzVP0PBQvbi9TqNN45j2qmLoP1HyrTqE I56jh2vwqttwDJjNYrZg2tdl5ZfwWiBe_bn2ZaEMEh4aI6bpQQrFL1PC9yty91RYWuhwMe3snUpJ naMJS70sIGF8nHNjSWc80mbZhWkO_MCVZ7c9x8U3OLT2fFwyhnAlvSMhSFwKW8vzLAnMbIHoH_nT _hcEo3Sim7Xw2vC19II9Cb9uYRDVwNMoTg31kZ3EH7lToyur5OWAw9z9L5Hm8vfkwnPm1zvD.Kqo h_WV09iE8sHkmQOM4wBx9URNnVUE1hmDLcuowNqd6WP3K7YdrWIjnh0viiGcqKrrs9Y.fsLQ0wK1 8nQsBGRAxctTjGCrF0L_IkE6vs2L5ZSUi8VGE3LsvPtT7ME2qEAcqJaX_XNW3Pm5.TYO6_.YpkV4 11BSEy8LWCRUcDQevfBrhjcHsjv2.XdozssTSrwnGi_NccGKaKNs7Q0RnVeSfHZ6MLdPEg9tam58 MsrRJZ0nhDPg3Dayowy0CYwmShjGoJouugGwa3mgHJUraHLBLmN1Esnm.SxvtqHsBc85v69IjAXI sb.rB0kJ06Nq.gTI5NMAONYDqXzfpL6n8tPS92i3NrAoKJiRhoMJ_JgYDdimVFPAWaXvXes_bgtj kksIYtmVkbwll8Qag0lwY2wdIETK5lY9IdG_jRP917F95fsJI5ws4_N0myvlhEY5vFcDR1rezY8d s5yHQLO_25uoTiPyKu3qub9yfetslWea8QDU0v5oF38_OUA3gvLWnthIzQ8kjj.xAuBCh07vj5oV r4.CBBDHYctdUoxcZVaJn_pdFWU7jpBjGu7Hhi5OpAZv.UuYmXe0gUWYGpKVFuiiI_XeL6M..Qvt eF.8gcbL_lrwaFKbmdXdU4vjIw0zsODhGHMNng5HHt6MQXWuA2YbUpi1C9cG2sAoaxW1TyK_ioC1 Ym6xtb3UkVljTg40lRg9qDpW7SJFD6zrV07bilcrpTBOnIiCYZubqvQcoge10JQdW1ddpo01mdFD BSU8jb70_swF_El1J0KOihaixCx5JOahq.TgFwOV7_VOgjzm0NJrDrpeWn1PVBC.nWcUtM52Lkcv SZlw5rEG79CknnxNFoWcHcMdSZpnGweVNrN0oJbkARQaLf9QOBPM_Pz23PvZU0GDd4Ee9I3clCNq LlL8hj.DJ7pzn3barkvsaGTeIedvMSIBEQBczgIHgroHe7k32iewE._9KeLHW_P.S_FlnGfrQLuJ sqonrEuklr_xD.6tT9mycoMzd1gF9ebSeVTB.17wGIyjMYuj6J9UsddHRvOGfFxqzev6aQL40VDt 6sVFcapG1QJbbjGGwrHKj7jblZpSFiKKmmZM4x10TCCyg6QNK8K5dLQ.ap6wDjUM3FPeplpLMb8Y k0PRZriv8RXVL6Wq_mMPfALPbe7gJ23I4M24pg6198fJY.517z.nkqbjCYzb8cViqk.ofn5CXMtJ UBdECd76XZvfuLom8ckceQg-- X-Sonic-MF: X-Sonic-ID: e5bf81c3-6637-40a6-b5a3-379dadce0242 Received: from sonic.gate.mail.ne1.yahoo.com by sonic309.consmr.mail.gq1.yahoo.com with HTTP; Thu, 29 Aug 2024 07:48:17 +0000 Received: by hermes--production-gq1-5d95dc458-7jxgc (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 1aa3b0f325db680bcd85a722ded5cfed; Thu, 29 Aug 2024 07:48:11 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable 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: security/nss targeting armv7 tries to compile armv8-a source code: nss/lib/freebl/aes-armv8.c Message-Id: <4C7FBDDC-35E8-46E2-A424-58F5779199F8@yahoo.com> Date: Thu, 29 Aug 2024 00:48:00 -0700 Cc: Tomoaki AOKI , Brooks Davis To: " gecko@freebsd.org" , FreeBSD ARM List , FreeBSD Mailing List X-Mailer: Apple Mail (2.3776.700.51) References: <4C7FBDDC-35E8-46E2-A424-58F5779199F8.ref@yahoo.com> 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.65.148: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.65.148:from]; RCPT_COUNT_FIVE(0.00)[5] X-Rspamd-Queue-Id: 4WvYLJ4ZWGz43gk nss/lib/freebl/Makefile has: ifeq ($(CPU_ARCH),arm) $(OBJDIR)/$(PROG_PREFIX)aes-armv8$(OBJ_SUFFIX): CFLAGS +=3D = -march=3Darmv8-a -mfpu=3Dcrypto-neon-fp-armv8 $(OBJDIR)/$(PROG_PREFIX)gcm-arm32-neon$(OBJ_SUFFIX): CFLAGS +=3D = -mfpu=3Dneon endif but targeting -mcpu=3Dcortex-a7 (an armv7) results in the likes of: cc -o FreeBSD15.0_OPT.OBJ/FreeBSD_SINGLE_SHLIB/aes-armv8.o -c -std=3Dc99 = -O2 -gline-tables-only -pipe -mcpu=3Dcortex-a7 . . . . -march=3Darmv8-a = -mfpu=3Dcrypto-neon-fp-armv8 aes-armv8.c cc: warning: ignoring extension 'sha2' because the 'armv7-a' = architecture does not support it [-Winvalid-command-line-argument] cc: warning: ignoring extension 'aes' because the 'armv7-a' architecture = does not support it [-Winvalid-command-line-argument] aes-armv8.c:14:2: error: "Compiler option is invalid" 14 | #error "Compiler option is invalid" | ^ from nss/lib/freebl/aes-armv8.c: . . . #include "secerr.h" #include "rijndael.h" #if ((defined(__clang__) || \ (defined(__GNUC__) && defined(__GNUC_MINOR__) && \ (__GNUC__ > 4 || (__GNUC__ =3D=3D 4 && __GNUC_MINOR__ > 8)))) && = \ defined(IS_LITTLE_ENDIAN)) #ifndef __ARM_FEATURE_CRYPTO #error "Compiler option is invalid" #endif #include . . . (The example happens to be for 3.103 .) Seems odd to me to have armv7 targeting have any dependency on armv8 encoded instructions that from well after armv7 was defined. (Even if the goal is to have the processor reject the instructions.) Note: I ran into this trying to see if I could build www/firefox in a armv7 jail on a aarch64 that supports armv7 code. BE_WASM for llvm*'s may be a waste of resources if armv7 based builds are just not going to work. (I do not normally build firefox.) =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Thu Aug 29 08:54:39 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 4WvZpq6QZLz5MZ70; Thu, 29 Aug 2024 08:54:43 +0000 (UTC) (envelope-from philip@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R10" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4WvZpq5vj7z4B6J; Thu, 29 Aug 2024 08:54:43 +0000 (UTC) (envelope-from philip@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1724921683; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=iqVxzLpbmGYmGenmmpHpnqWlSQgPEX5v2823oApI520=; b=GGPi3PCQRIUbz1J0G/ityv1Bbaq1hGcBuXK7LnTGty78AbKTJJiRxc0bhYIYQVYXChsHTa owAjcTDQy94K4gyLA7/QEBmuoy7364uIYRGbMpJRzGkvstGTmncpSi9IPMiq/5h1kwDXtX u6iJF81eX5C8AasyAbgZOBqiMjZkdQDY6fkDJYGzfcDCTCOFgEb0XYbuKErnECyZak4Yo/ 4pWMHpDKVNiIuhVsUtwcv00+FCjZbVPjEjVJUM6V8PCCkK15LiCBpa052nIIp1ne5uh3Jw z3HfQmZwCpMdPVcLVobrLhFx+BNegqF8KYxepp5KjDEoW86sAZdC0YigsPUpzg== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1724921683; a=rsa-sha256; cv=none; b=LfTxsWQQMwZ8i/uOlkug81ZyG8MuM/UREDXZFtaUzJyrXiEhVdDeVqS9BqdNZEO9m9DsPZ VthLomiLyf02QBJtIocvZlkSJU2qjH5ndvhu+W2M9rfOZolEZG05w8O+iLN6N5XU6vrfxd 2hDUqdiuawk9hKdu5MaibsQI9+NpzQz4jEs8ZuPnQTICH6zRk4h8y6oKFLGwrXq0xf0tnL fOjGVCwH472Ss2eiX2cUIo2PbSsf+q3UZJYYnIzF9H6GXUW9zBmr/XcRwQJoaHPSHTfLSp pSVm7am8FhN8m2bhYT03Zv65PMJABBf1FFn/Cd7oR9Tdouk9y85gYa8F1YY/KQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1724921683; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=iqVxzLpbmGYmGenmmpHpnqWlSQgPEX5v2823oApI520=; b=Jc7xuJRhgiEjPEI1IInVdtlVoXO4DvJflcBdAM1Cp+/omFGFZLWpiaC1nQBr9FKq0c/xEd OlZu6UkxO74porAHkMpZHMJPpCPOnSWvLz/TFnvNJl8MviGZZLOw20hYBXaJX6Grss4v92 WToMwoHfMqKNFRiZdq2+a8FoB83h4+K+rMkccNliI9cksv2u2IfI37htUSebzDEn2PbVLW uLlNzDlsvWbAE4OjO5vMDeWqfFCEco7LP7hg4f1LeG3MHhdQbCuvX1/WkFCQjiJ8QJb3NO NBX4sjnfS6HH7EcGhTnq+I3JVqSZqeR+ho2LpsV1c7ui6i2mq6OXVPRfGK2RBw== Received: from fauth2-smtp.messagingengine.com (fauth2-smtp.messagingengine.com [103.168.172.201]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: philip/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4WvZpq54j0zFR8; Thu, 29 Aug 2024 08:54:43 +0000 (UTC) (envelope-from philip@freebsd.org) Received: from phl-compute-03.internal (phl-compute-03.nyi.internal [10.202.2.43]) by mailfauth.nyi.internal (Postfix) with ESMTP id 044E8120006E; Thu, 29 Aug 2024 04:54:42 -0400 (EDT) Received: from phl-mailfrontend-01 ([10.202.2.162]) by phl-compute-03.internal (MEProxy); Thu, 29 Aug 2024 04:54:43 -0400 X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeftddrudefgedgtdelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgfnhhsuhgsshgtrhhisggvpdfu rfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnh htshculddquddttddmnecujfgurhephffvvefufffokfgjfhggtgesthdtmhdtredttden ucfhrhhomheprfhhihhlihhpucfrrggvphhsuceophhhihhlihhpsehfrhgvvggsshgurd horhhgqeenucggtffrrghtthgvrhhnpefggfefieegtedtledtgfevtdfftdegvdehueei teehteefieefveevtedvvdekgeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmh epmhgrihhlfhhrohhmpehphhhilhhiphdomhgvshhmthhprghuthhhphgvrhhsohhnrghl ihhthidqudduieeivdeivdegkedqvdefhedukedttdekqdhphhhilhhipheppehfrhgvvg gsshgurdhorhhgsehtrhhouhgslhgvrdhishdpnhgspghrtghpthhtohepfedpmhhouggv pehsmhhtphhouhhtpdhrtghpthhtohepmhgrrhhklhhmiheshigrhhhoohdrtghomhdprh gtphhtthhopehfrhgvvggsshguqdgrrhhmsehfrhgvvggsshgurdhorhhgpdhrtghpthht ohepfhhrvggvsghsugdqphhorhhtshesfhhrvggvsghsugdrohhrgh X-ME-Proxy: Feedback-ID: ia691475d:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 29 Aug 2024 04:54:41 -0400 (EDT) From: Philip Paeps To: Mark Millard Cc: FreeBSD ARM List , FreeBSD Mailing List Subject: Re: ampere2 did not even try to build main-armv7-default: it is only trying to build main-arm64-default Date: Thu, 29 Aug 2024 16:54:39 +0800 X-Mailer: MailMate (1.14r6059) Message-ID: In-Reply-To: References: <90DDBA5B-1D0C-402F-88F5-704DD7D439B9@freebsd.org> <0FD5A72E-BFFF-422C-B38F-7EDFB832FAFB@freebsd.org> 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 Content-Type: text/plain; format=flowed On 2024-08-27 10:34:18 (+0800), Mark Millard wrote: > main-arm64-default on ampere2 has started building as of Tue, 27 Aug > 2024 01:58:37 GMT. 14609 were queued. > > So, unless that is stopped, it will likely be days before > main-armv7-default would be started. The arm builds are currently scheduled like this: ampere1: - quarterly arm64.aarch64 13.3-RELEASE 133arm64 -a ampere1: - quarterly arm.armv7 releng/13.3 133releng-armv7 -a ampere1: - quarterly arm64.aarch64 14.0-RELEASE 140arm64 -a ampere1: - quarterly arm.armv7 releng/14.0 140releng-armv7 -a ampere2: - default arm64.aarch64 main main-arm64 -a ampere2: - default arm.armv7 main main-armv7 -a ampere3: - default arm64.aarch64 13.3-RELEASE 133arm64 -a ampere3: - default arm.armv7 releng/13.3 133releng-armv7 -a ampere3: - default arm64.aarch64 14.0-RELEASE 140arm64 -a ampere3: - default arm.armv7 releng/14.0 140releng-armv7 -a ampere2 should start building armv7 when it finishes with its current aarch64 build. I'm keeping an eye on this one. I've also got the next set of FreeBSD-CURRENT builds ready to upgrade it when it goes idle. Philip From nobody Thu Aug 29 09:00:23 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 4WvZwW0s3sz5MZHr for ; Thu, 29 Aug 2024 08:59:39 +0000 (UTC) (envelope-from ronald@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R10" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4WvZwV73JQz4D78; Thu, 29 Aug 2024 08:59:38 +0000 (UTC) (envelope-from ronald@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1724921979; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=ydvVDulfk2AUtlpZcVxZ5f2DCNj/Oxcgq9Kb5lpLdMs=; b=hUkQt7C48KYTsjzmHawGhk2HlFH0X26lhVu/fjJg8y27hC1Agwra7Md/S1QPw5QuYLmRfM ATz771YrSfNqlmGDFbz37wMuHKER2ZS5pzNpXE7cUTwz221Zi2nLdIAwO6opo3hcbJ/9kz BgCxmxYES41ZUYxAlZq9cBSKFETf+BZEHWXPmUKKaZk+Q8u4HUJwHBnAwFBcVN3MVNOUrj UvV1W+LQkZBPa/RZYb3IL03sGq00taQ4pKOVIaCp8ExFoyfkt6XMvPf3yMWtHNbRbj1XHa ZklXwncVeJVpwZPF1YMffl+Ibpe2CsdMgJK3znTbgYnHDWRX4/XdSYvO0YC8dw== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1724921979; a=rsa-sha256; cv=none; b=YjQOlt9Xcy2ZWIGNBSsta/w2Af9fjZ8riT3kHSM7hOMmwSvZT9HeCqRFbQGV1w1qXx8jNF apmxGxfBgVte+1veYJQTIOExI9COFsVM+wZG/kC+8Ddxe8BQmZRb7YJhY3vFAdt0ANnbBS 172N8560c5dxrM5AFMbRAvboiPN/arkgzE++u7cBzNu0ghydxrQaO5MYXuN+744Xq6L9wG NuM6Ngzm6RCKeB9RTEgCbk1Z2204U89xy3bBIJRBlBJR1EHs1bJKnj40Mr+GQe4V5vqt5/ sQ7ErONBdaMH55O8zvh3vqIAjTSdKjmw65GoxBXAwDdsCE1AVkF2xF4oCkeKtQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1724921979; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=ydvVDulfk2AUtlpZcVxZ5f2DCNj/Oxcgq9Kb5lpLdMs=; b=vIShYaNnA33RFijaUpq+ABF+XTaKCwjkl2ApqYm4dynGyAiIpoQEmbFG9fn65j+C5xQBv3 j3tnCEWniqzNPUC1wLxnh026AmUWIUCsQI2XmmzXya3aKHkXmzerutxZajM/j7rOXDlGzP I3Gy8UyDarSa1Y8KWtlRH7asIRsV+8QOffE7Snf7uyXeNPfPWet0R6RxuVLQDVI2tFhSF/ Ro76embtDXEJBRPv8oVb6TxdXTWakCICcAHg1A89BnVTvzwBVkwxf00/Z74lV5S2Q2rKWA HyTBLkdxfFNeITBFECJNiaXM1Mn3aTbsywL4+eqOFW4LfRNNuC/FVS4RdzHM0g== Received: from [IPV6:2001:1c00:2709:2010:ce9:4631:c5ff:6dc7] (2001-1c00-2709-2010-0ce9-4631-c5ff-6dc7.cable.dynamic.v6.ziggo.nl [IPv6:2001:1c00:2709:2010:ce9:4631:c5ff:6dc7]) (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) (Authenticated sender: ronald/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4WvZwV4GbtzFwM; Thu, 29 Aug 2024 08:59:38 +0000 (UTC) (envelope-from ronald@FreeBSD.org) Message-ID: Date: Thu, 29 Aug 2024 11:00:23 +0200 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 User-Agent: Mozilla Thunderbird Subject: Re: OT, self-signed ssl certificate generation To: bob prohaska , freebsd-arm@freebsd.org References: Content-Language: en-US From: Ronald Klop In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 8/4/24 03:48, bob prohaska wrote: > [no ssl list, posting here because it might be a platform issue] > > In trying to get ssl working for apache24 I tried to follow the > instructions for self-signed certificate generation at > https://docs.freebsd.org/en/books/handbook/security/index.html > in section 16.8.1, Generating Certificates. > > The first example for generating a key and signing request > behaved as expected, generating a cert.key and req.pem file. > > The second example, for a self-signed certificate, adjusted to: > openssl req -new -x509 -days 365 -sha3-512 -keyout host.key -out host.crt Hi, This command works for me. So I think you should look further what fails. That it does not prompt for user input sounds like openssl does not execute properly. What is the exit code of running the command? Does it give any output? Mine gives: $ openssl req -new -x509 -days 365 -sha3-512 -keyout host.key -out host.crt .+.+...+.....+.+...............+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++*.....+...+...........+...+..........+...........................+......+..+.+.................+.........+...+...+..........+..............+.+..+...+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++*..+..............+...+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ ..........+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++*...+...+...+.+......+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++*..+.........+...+.+............+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Enter PEM pass phrase: Verifying - Enter PEM pass phrase: ----- You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. ----- Country Name (2 letter code) [AU]:NL State or Province Name (full name) [Some-State]:NH Locality Name (eg, city) []:Amsterdam Organization Name (eg, company) [Internet Widgits Pty Ltd]:Henk Organizational Unit Name (eg, section) []: Common Name (e.g. server FQDN or YOUR name) []:henk.example.org Email Address []:henk@example.org Regards, Ronald. > to place the output files in the working directory, generated only an > empty host.key and no host.crt > > It also didn't prompt for user input, which the first example > did ask for. > > Any hints as to what I'm doing wrong would be much appreciated! > > Thanks for reading, > From nobody Thu Aug 29 09:04:08 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 4Wvb1n0p1bz5Mb85; Thu, 29 Aug 2024 09:04:13 +0000 (UTC) (envelope-from meloun.michal@gmail.com) Received: from mail-wm1-x331.google.com (mail-wm1-x331.google.com [IPv6:2a00:1450:4864:20::331]) (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-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Wvb1m6DPWz4DNp; Thu, 29 Aug 2024 09:04:12 +0000 (UTC) (envelope-from meloun.michal@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-wm1-x331.google.com with SMTP id 5b1f17b1804b1-428e1915e18so3428405e9.1; Thu, 29 Aug 2024 02:04:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1724922251; x=1725527051; darn=freebsd.org; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :sender:from:to:cc:subject:date:message-id:reply-to; bh=Ie1l6zB59PV1FsKJ02copGSpO2j7unYz35K1pLMWyMQ=; b=DnkgINKITpUsxicLztMTwPdbH6d+hDoCA5qkcvQ+vkwOGU4mdHkjRQhA3XroqfDLfS oyXB4Din3EOLEowpCyRJsUzijBx37So6GdW6vfUV8wum2LVt3HKA/a50+x9LRSX6Vl+4 ATsykNH+q4yFMIXABS2FBU11SbvRVBG5WVt3Wc9Vo169JTG6n3+9oC4bxTXZSYgyiOED kBR2w3Sv3vnNZ92k5d9rRnnnGF4LNSDstGRRXBZNBE3pUO8SMnM4Boh1mSyE+Y97Wfid VUfJ33ByafvbKq/zLNujThkR9Tf9WViltYHYzGSciNm6pxxGss/LDMqZuq1UayGCAEag gQbQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1724922251; x=1725527051; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :sender:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=Ie1l6zB59PV1FsKJ02copGSpO2j7unYz35K1pLMWyMQ=; b=uojA3QuQb/GZiJQuJbBU63YZd5v7Aq5c6DVc7GzlOiCxeeUfgx1QNKW0rnXNpeQ35f 3gpEYWMJHhZS1XPznJ/emP4St1hTgoF2BOE5a91Man3X39jSDTpjol5crB+w0kCgQ/5L HzUqqYFi+WqGEFsOGcEqIp/0T9JNfaLUKYXp0RKaM1GyFfOuc8FDzplgsG5WFfm+Z1qH eZxQR9uqpmHOiq0ujlsOYPsVpf8RTuR0fxhqLgzwItjt6oCyYRZnvjP9xHG8g3MHrrP+ X2WyarVsoUn9K+Uc2qn4HWJNEfNMti2gv1C8dFbyDkmW1NIXpZDtZLvZk/JNCPkb2pua GWwA== X-Forwarded-Encrypted: i=1; AJvYcCUSUtZiyHEgwYxkEcrKmrfQHdaHwApXMrYwybSKiNCurFEBhYkqRcHa7uj63BXkbKk663hHUo/c8k+iMwJOhQ==@freebsd.org, AJvYcCVk6sOVsEV7+2kDlAYuK0E85dNf0SxU+xAK6ZgjPBJSHsM7WqQt7CGj6XZCocjQoWG83eazxwE=@freebsd.org, AJvYcCXRawABGvc4dBRP4NfNJ1+KDTM40IuR8VgZPRZVuNcjItjPz6fvyRcAaKV1PTjeF6tvXQDdEDg=@freebsd.org, AJvYcCXa7mZExzw6PcmF2YjLd6k8VZHTiuFcR6+QnQVm7D9XA3TPl7vJ6ruwZLE2lo3BAp7ex759KZlD+mJUNMg=@freebsd.org X-Gm-Message-State: AOJu0YxU48FO23+qIP+0bupQJTmlcetEiecLS0mMAhHHzXb+XxhdObyK WPyAx5HgYRVjncC4FFIo8wI4EKKEB2+PsKetC0KSlnP+QEGaAb3H X-Google-Smtp-Source: AGHT+IH6uQcnkhflEqPdBKfwLpR3cwPuRMhEek9INbt9ovKcCHonLOrU6bHSOzIpg7VGP7FefyqjUA== X-Received: by 2002:a05:600c:a49:b0:426:51ce:bb14 with SMTP id 5b1f17b1804b1-42bb27a2863mr12256985e9.30.1724922250071; Thu, 29 Aug 2024 02:04:10 -0700 (PDT) Received: from ?IPV6:2001:67c:14a0:5fe0:dc9d:8b84:f911:72d3? ([2001:67c:14a0:5fe0:dc9d:8b84:f911:72d3]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-42bb6a10353sm10149345e9.1.2024.08.29.02.04.09 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 29 Aug 2024 02:04:09 -0700 (PDT) Message-ID: Date: Thu, 29 Aug 2024 11:04:08 +0200 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 User-Agent: Mozilla Thunderbird Subject: Re: security/nss targeting armv7 tries to compile armv8-a source code: nss/lib/freebl/aes-armv8.c To: Mark Millard , "gecko@freebsd.org" , FreeBSD ARM List , FreeBSD Mailing List Cc: Tomoaki AOKI , Brooks Davis References: <4C7FBDDC-35E8-46E2-A424-58F5779199F8.ref@yahoo.com> <4C7FBDDC-35E8-46E2-A424-58F5779199F8@yahoo.com> Content-Language: en-US From: Michal Meloun In-Reply-To: <4C7FBDDC-35E8-46E2-A424-58F5779199F8@yahoo.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit 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)[]; TAGGED_FROM(0.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US] X-Rspamd-Queue-Id: 4Wvb1m6DPWz4DNp On 29. 8. 2024 9:48, Mark Millard wrote: > nss/lib/freebl/Makefile has: > > ifeq ($(CPU_ARCH),arm) > $(OBJDIR)/$(PROG_PREFIX)aes-armv8$(OBJ_SUFFIX): CFLAGS += -march=armv8-a -mfpu=crypto-neon-fp-armv8 > $(OBJDIR)/$(PROG_PREFIX)gcm-arm32-neon$(OBJ_SUFFIX): CFLAGS += -mfpu=neon > endif > > but targeting -mcpu=cortex-a7 (an armv7) results in the likes of: > > cc -o FreeBSD15.0_OPT.OBJ/FreeBSD_SINGLE_SHLIB/aes-armv8.o -c -std=c99 -O2 -gline-tables-only -pipe -mcpu=cortex-a7 . . . . -march=armv8-a -mfpu=crypto-neon-fp-armv8 aes-armv8.c > cc: warning: ignoring extension 'sha2' because the 'armv7-a' architecture does not support it [-Winvalid-command-line-argument] > cc: warning: ignoring extension 'aes' because the 'armv7-a' architecture does not support it [-Winvalid-command-line-argument] > aes-armv8.c:14:2: error: "Compiler option is invalid" > 14 | #error "Compiler option is invalid" > | ^ > > from nss/lib/freebl/aes-armv8.c: > > . . . > #include "secerr.h" > #include "rijndael.h" > > #if ((defined(__clang__) || \ > (defined(__GNUC__) && defined(__GNUC_MINOR__) && \ > (__GNUC__ > 4 || (__GNUC__ == 4 && __GNUC_MINOR__ > 8)))) && \ > defined(IS_LITTLE_ENDIAN)) > > #ifndef __ARM_FEATURE_CRYPTO > #error "Compiler option is invalid" > #endif > > #include > . . . > > (The example happens to be for 3.103 .) > > Seems odd to me to have armv7 targeting have any dependency on > armv8 encoded instructions that from well after armv7 was > defined. (Even if the goal is to have the processor reject the > instructions.) > The short answer is that nss works fine (compiled with default options). The longer story is that nss dynamically determines the optimal/fastest implementation of various cryptographic routines. Because of this, you need to compile all versions - basic, using neon, or using 32-bit armv8 encryption instructions (sha2, aes)... Passing -mcpu or -march will break everything. This is probably a small problem with nss make (and there is a question what the expected behavior is), but the actual impact of this bug for freebsd users is imho close to zero.. Michal Meloun > > Note: I ran into this trying to see if I could build www/firefox > in a armv7 jail on a aarch64 that supports armv7 code. BE_WASM > for llvm*'s may be a waste of resources if armv7 based builds > are just not going to work. (I do not normally build firefox.) > > === > Mark Millard > marklmi at yahoo.com > > From nobody Fri Aug 30 00:06:01 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 4Wvz2R2nV4z5Mgd0 for ; Fri, 30 Aug 2024 00:06:07 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [50.1.20.27]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "generic", Issuer "generic" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Wvz2Q6cMyz4hbl; Fri, 30 Aug 2024 00:06:06 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Authentication-Results: mx1.freebsd.org; none Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.17.1/8.17.1) with ESMTPS id 47U0620h003021 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Thu, 29 Aug 2024 17:06:02 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.17.1/8.17.1/Submit) id 47U062UF003020; Thu, 29 Aug 2024 17:06:02 -0700 (PDT) (envelope-from fbsd) Date: Thu, 29 Aug 2024 17:06:01 -0700 From: bob prohaska To: Ronald Klop Cc: freebsd-arm@freebsd.org, bob prohaska Subject: Re: OT, self-signed ssl certificate generation Message-ID: References: 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 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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:7065, ipnet:50.1.16.0/20, country:US] X-Rspamd-Queue-Id: 4Wvz2Q6cMyz4hbl On Thu, Aug 29, 2024 at 11:00:23AM +0200, Ronald Klop wrote: > > > > In trying to get ssl working for apache24 I tried to follow the > > instructions for self-signed certificate generation at > > https://docs.freebsd.org/en/books/handbook/security/index.html > > in section 16.8.1, Generating Certificates. > > > > The first example for generating a key and signing request > > behaved as expected, generating a cert.key and req.pem file. > > > > The second example, for a self-signed certificate, adjusted to: > > openssl req -new -x509 -days 365 -sha3-512 -keyout host.key -out host.crt > > > Hi, > > This command works for me. So I think you should look further what fails. > That it does not prompt for user input sounds like openssl does not execute properly. What is the exit code of running the command? > Does it give any output? > The first thing it prompted for was a pass phrase. There being no reason to have one, I simply hit Enter. Eventually I accidentally discovered that providing a passphrase allows certificate and key generation to proceed. But, I don't see any reason for a passphrase on a self-signed certificate key. If I were sending the certificate elsewhere for signing it might make sense. Am I missing something? In the meantime I learned of security/xca and started reading the docs at https://hohnstaedt.de/xca/index.php/documentation/manual which has proved a large bite to swallow. In particular, the relationship between a host certificate and a CA certificate eludes me. Perhaps putting a plaintext password in the apache config file isn't so bad in comparison if it works! > Mine gives: > $ openssl req -new -x509 -days 365 -sha3-512 -keyout host.key -out host.crt [big snip] > ..........+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++*...+...+...+.+......+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++*..+.........+...+.+............+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > Enter PEM pass phrase: > Verifying - Enter PEM pass phrase: > ----- > You are about to be asked to enter information that will be incorporated > into your certificate request. > What you are about to enter is what is called a Distinguished Name or a DN. > There are quite a few fields but you can leave some blank > For some fields there will be a default value, > If you enter '.', the field will be left blank. > ----- > Country Name (2 letter code) [AU]:NL > State or Province Name (full name) [Some-State]:NH > Locality Name (eg, city) []:Amsterdam > Organization Name (eg, company) [Internet Widgits Pty Ltd]:Henk > Organizational Unit Name (eg, section) []: > Common Name (e.g. server FQDN or YOUR name) []:henk.example.org > Email Address []:henk@example.org > If I enter a non-null passphrase I see functionally what you see. Probably I should just accept the necessity of a passphrase and resume trying to get apache working with https; getting chromium to accept a self-signed certificate is proving difficult. Then the original goal of getting sendmail to use tls will be a little bit closer. That's what started the whole fire drill. Thanks for writing! bob prohaska From nobody Fri Aug 30 01:06: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 4Ww0NQ6qMNz5Mm92 for ; Fri, 30 Aug 2024 01:06:46 +0000 (UTC) (envelope-from saper@saper.info) Received: from q.saper.info (q.saper.info [IPv6:2605:2700:0:2:a800:ff:fec7:5c61]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature ECDSA (P-384) client-digest SHA384) (Client CN "q.saper.info", Issuer "E5" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Ww0NQ44S1z4n5c; Fri, 30 Aug 2024 01:06:46 +0000 (UTC) (envelope-from saper@saper.info) Authentication-Results: mx1.freebsd.org; none Received: from q.saper.info (localhost [127.0.0.1]) by q.saper.info (8.18.1/8.18.1) with ESMTPS id 47U16bRB002952 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Fri, 30 Aug 2024 01:06:37 GMT (envelope-from saper@saper.info) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=saper.info; s=Sep2014; t=1724979997; bh=O1+/vUzv9DZ7OvmokMxvnYW7vw9hyeEOSAfE489T7A4=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=qhjtZKs6zReY+zHZU6if70RUvZHX9pxYkB6qIWSHlP1k5j03WkvlB+bo9h5PZvVk+ PTm4nF8ULRYwRlhsNf1jmIUHFO+MDFx4MvO06LweKx+e+5mVYXBB4xovSFFohvyQJR qdWsTj3kdIlB1bs+tYAj5yDfn9z2/mkGQjXUJ2q8= Received: from localhost (saper@localhost) by q.saper.info (8.18.1/8.18.1/Submit) with ESMTP id 47U16bBi002946; Fri, 30 Aug 2024 01:06:37 GMT (envelope-from saper@saper.info) X-Authentication-Warning: q.saper.info: saper owned process doing -bs Date: Fri, 30 Aug 2024 01:06:36 +0000 From: Marcin Cieslak To: bob prohaska cc: Ronald Klop , freebsd-arm@freebsd.org Subject: Re: OT, self-signed ssl certificate generation In-Reply-To: Message-ID: References: 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 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="2201072851-248282397-1724979997=:967" 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:47066, ipnet:2605:2700::/32, country:US] X-Rspamd-Queue-Id: 4Ww0NQ44S1z4n5c --2201072851-248282397-1724979997=:967 Content-Type: text/plain; charset=US-ASCII; format=flowed On Thu, 29 Aug 2024, bob prohaska wrote: > Probably I should just accept the necessity of a passphrase and > resume trying to get apache working with https; getting chromium > to accept a self-signed certificate is proving difficult. For a fully automated generation you can try something like this: openssl req -new -x509 -days 365 \ -sha3-512 -newkey rsa:4096 \ -keyout host.key -out host.crt -nodes \ -subj '/CN=example.org' -addext "subjectAltName = DNS:example.org" Marcin --2201072851-248282397-1724979997=:967 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: BASE64 Content-Description: S/MIME Cryptographic Signature Content-Disposition: attachment; filename=smime.p7s MIIOdgYJKoZIhvcNAQcCoIIOZzCCDmMCAQExDzANBglghkgBZQMEAgEFADAL BgkqhkiG9w0BBwGgggq9MIIEvDCCA6SgAwIBAgIQeEqpEhjRpCYIUTzTZlVD ozANBgkqhkiG9w0BAQsFADBMMSAwHgYDVQQLExdHbG9iYWxTaWduIFJvb3Qg Q0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEGA1UEAxMKR2xvYmFs U2lnbjAeFw0yMDA5MTYwMDAwMDBaFw0yOTAzMTgwMDAwMDBaMFsxCzAJBgNV BAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMTEwLwYDVQQDEyhH bG9iYWxTaWduIEdDQyBSMyBQZXJzb25hbFNpZ24gMSBDQSAyMDIwMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAvxvJBqEapaux2/z3J7fFslRO WjKVJ5rCMfWGsg17dmD7NSnG7Spoa8d3htXsls1IMxoO8PyouQajNQqYmlYo xinlqenMNv7CJyEKMOAtglBmD6C/QC7kT+dSx4HfSTs8xmv8veJOldMzF8S/ BEn/tD4w/Dvpg+oXOqDyOiHPTacRFK0QHoq5eEbBmVS8W0rwcaRotO9fGTA+ NjF0My7GLRNK0eMPGh2hcPZURQhXy7wRQ8XFIfEA6kaQHHN22ncnVtwqiTmA wTR+4GNNVinG3KjNZLAVSnGrdCvT2I4Zo19hKy5PX6o7wrVXvMR4zV5VBFwV 6ZDM+xewao7Mup+SbwIDAQABo4IBiTCCAYUwDgYDVR0PAQH/BAQDAgGGMB0G A1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDASBgNVHRMBAf8ECDAGAQH/ AgEAMB0GA1UdDgQWBBSFu/DMxDa1CmJ2o5kuj7s6aq3FUTAfBgNVHSMEGDAW gBSP8Et/qC5FJK5NUPpjmove4t0bvDB6BggrBgEFBQcBAQRuMGwwLQYIKwYB BQUHMAGGIWh0dHA6Ly9vY3NwLmdsb2JhbHNpZ24uY29tL3Jvb3RyMzA7Bggr BgEFBQcwAoYvaHR0cDovL3NlY3VyZS5nbG9iYWxzaWduLmNvbS9jYWNlcnQv cm9vdC1yMy5jcnQwNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2NybC5nbG9i YWxzaWduLmNvbS9yb290LXIzLmNybDBMBgNVHSAERTBDMEEGCSsGAQQBoDIB KDA0MDIGCCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9y ZXBvc2l0b3J5LzANBgkqhkiG9w0BAQsFAAOCAQEAWWtqju12g524FdD2HwUX U1rSxeM5aSU1cUC1V/xBjXW0IjA7/3/vG2cietPPP/g3lpoQePVJpQAKZml8 1fHwPPivFK9Ja41jJkgqGzkORSC0xYkh2gGeQg1JVaCzcrRzJElRjT442m6F pbLHCebxIHLu0WBNjLZreB6MYMaqdPL6ItbXtD/BU4k517cEuUbczoBFZAra jq7oUBWXuroln5AMnRwVNwgJN4Np0s4kkJ94KepzbFOLzcbnfUB0+xT4foXm bM0GmmcPGOy0qvqEHJsBwDZXDxIk8oqCnnLngi7N94Sn4eTcmpZ9NH2dDN1O TEPVXgRG5X1pBcNtMWG6MDCCBfkwggThoAMCAQICDCKqoJRMYYx5sYJHGzAN BgkqhkiG9w0BAQsFADBbMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFs U2lnbiBudi1zYTExMC8GA1UEAxMoR2xvYmFsU2lnbiBHQ0MgUjMgUGVyc29u YWxTaWduIDEgQ0EgMjAyMDAeFw0yMzAzMDcxNjExMDlaFw0yNjAzMDcxNjEx MDlaMDwxGTAXBgNVBAMMEHNhcGVyQHNhcGVyLmluZm8xHzAdBgkqhkiG9w0B CQEWEHNhcGVyQHNhcGVyLmluZm8wggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAw ggIKAoICAQC8MB3fTYVrTadH5qE2CIa4VLvlL6QHgDriMRLkTA49SPszYCO0 fZTEpdSw8fc6kK9p2fD63LAfOHeD7jzey5aHBzpIGlxeFkn0Ce2BCYY5yLxK i9byoCwrpLchTR1Itpk1w+zy5E4T9KBTL1+c+w+TKpaIvFLXtjZtz4wQGi0p e/nRkRK9htGG3mETh+APitedl+ImGaI8NK9PELxuSkXnYAvGPpnXir8vbszk tJU1b0TevL/i3Sy6fhOhunZmTo1QDM7Zw4UyVjkQgTvL3y4I0tIrVjlam08x XZeMp+i/Gl51eHGvRVfvdJUJAjrWhrFEp8+2FZouWxWzAlHdd2sRp1AekNdP CeRgHeIF6uNtSseL1grKAjU+4BiixWPp1y1niB0humoQHoub/6fO/mU+//rW l3gTwZNu4FuKgZlfPw+qnvuka0c9dUNIZRCE5z8yXjS8R9yZWirnHNhYxf/e R2y4jaiHzPAjZlZZ2rGx8xVfB2n2JsAicj2+ZxmXlQ1yd5RW1pfxG3cdNNC5 uZ+j4JIN2ElsIjEKmMn9gHdoaEMAy/ENwNiMDBadLnc8qWirq/Ktp2dBSf2y /sH9xMpVyk8wuYjpbCnX4xslAensno5A20MYdKGPRFaItEhNPNbfzc1+4br8 exoXFX1F9ZJK9gGUO2nLbdRycphdyzxzgQIDAQABo4IB2jCCAdYwDgYDVR0P AQH/BAQDAgWgMIGjBggrBgEFBQcBAQSBljCBkzBOBggrBgEFBQcwAoZCaHR0 cDovL3NlY3VyZS5nbG9iYWxzaWduLmNvbS9jYWNlcnQvZ3NnY2NyM3BlcnNv bmFsc2lnbjFjYTIwMjAuY3J0MEEGCCsGAQUFBzABhjVodHRwOi8vb2NzcC5n bG9iYWxzaWduLmNvbS9nc2djY3IzcGVyc29uYWxzaWduMWNhMjAyMDBMBgNV HSAERTBDMEEGCSsGAQQBoDIBKDA0MDIGCCsGAQUFBwIBFiZodHRwczovL3d3 dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzAJBgNVHRMEAjAAMEkGA1Ud HwRCMEAwPqA8oDqGOGh0dHA6Ly9jcmwuZ2xvYmFsc2lnbi5jb20vZ3NnY2Ny M3BlcnNvbmFsc2lnbjFjYTIwMjAuY3JsMBsGA1UdEQQUMBKBEHNhcGVyQHNh cGVyLmluZm8wHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB8GA1Ud IwQYMBaAFIW78MzENrUKYnajmS6PuzpqrcVRMB0GA1UdDgQWBBTW/RrdlRFR y6MgS7liTThMnQA5ozANBgkqhkiG9w0BAQsFAAOCAQEAAwoUJShHMueocVlD 1+vYJbTTTbk9tabr2L4Iyyy4Btu1d1wwl6d9Yx2N9qaVERWcEeP0aR+NB2B7 xIKl/ZnZVuSxep0Raw4s284a/jSIJlsAi4SJItDCU2VrYJDWxP7MxzZHnzPI MLDoTHXPV18gvYTewoNk5/Yo89Kb0v/GpPTpP2sVdrWLHa4uKUHYrAZ0aByp kNw6lXp6o6DXvXaOd6KDTQN5XhmmHwLnuLceODF1t9gicsZIOY+KAxN6YZ6t EqwN48b4OFMpckDE3fm1iTZRqnEIqUHOKOcoCImkub1woEN0zXDQmLXaZigl uVztWSTM4/fapWLrlHBNxfjs1TGCA30wggN5AgEBMGswWzELMAkGA1UEBhMC QkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExMTAvBgNVBAMTKEdsb2Jh bFNpZ24gR0NDIFIzIFBlcnNvbmFsU2lnbiAxIENBIDIwMjACDCKqoJRMYYx5 sYJHGzANBglghkgBZQMEAgEFAKCB5DAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0yNDA4MzAwMTA2MzZaMC8GCSqGSIb3DQEJ BDEiBCA8dGrcrU2fLKLprojoswVmCCUCNma1z63DkMhB46IgzTB5BgkqhkiG 9w0BCQ8xbDBqMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYwCwYJYIZIAWUD BAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIB QDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDANBgkqhkiG9w0BAQEFAASCAgAj gMse3hhJmnLDoJxij3//NbocQ+XbH6r1HMuvMU5LJSQ3zanSaQcTwIeFUVcm 7Lo56tI19fpYLVIaMTFyW1QmVXgOCtSwRakFr2H6ulEndPVcH0jOEq+0O+cf GLo4M9BffoflN3rWjtFAQJdZGv7weC/XLdxUW3JR0T31Z3sJdiUO+Iyri85I 5BrRO/eS8g686ft05N3SfPVkp2V0FbDm9zDhmUzBkThEnOjUBk+U/yuCh6e6 4cRuGXExH9/rCt/sU5uURFUApz4wLgaVu0oJMJl06n5JqQGKl+F9KPqcPEZb EFfb6iAH8IfEyDGSEBi3MiBWT5qZU97Xdi3xHqL8jCuKYMVpxm7aJdtdXFKN 2/PV3JmebS607BrHbWW9YAA+21t8cdLS9hilTG96h7PqT/Jh9F8hbkcmG5Sl lwmB0n4JxS8ZGYp9p3I5pu1RVDFaZYBQdx9rpcEVK8rJZJa/0nbcNkQqMfCF Q4KF9KnQorbpp10sqcVAE/L+Nk2YuHY+BqTdPijJkKBaob/Rr3hW0R5SJ6TS Nxxb+ZRtFCp/TrMapIWnUmjMoZh4CBJejBWF2hchNva9yGH2ioRt/IBCIUrS 0XtHREnBPfRigReNAoFQpTdsPPUNJsNSkzwfRlghOxhvogz53fxAed/7sU5L prtt82RCB1SmE2WysTx0TQ== --2201072851-248282397-1724979997=:967-- From nobody Fri Aug 30 23:24:15 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 4WwZ410KZvz5T6bc for ; Fri, 30 Aug 2024 23:24:33 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic306-21.consmr.mail.gq1.yahoo.com (sonic306-21.consmr.mail.gq1.yahoo.com [98.137.68.84]) (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 4WwZ400qyYz3xx5 for ; Fri, 30 Aug 2024 23:24:32 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=jUK4LyaX; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.68.84 as permitted sender) smtp.mailfrom=marklmi@yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1725060269; bh=4hLFDub8ks/0+4GfpH4g2CBMtPkt2rJYNtyrHywRtew=; h=From:Subject:Date:To:References:From:Subject:Reply-To; b=jUK4LyaXK+QSLoY3/wrLA0B/NgI/DLH2F82SkAmnz1zO7Lhzv+cIy57pEQwumagb76YRtMoXITMZoGwVh/2Ex4AT2mt4ixUV2DOLICpoiU+zu2NvEL51S7M+oYK2PpexErX140v4nNl+d3fyyjLF7Ig4etrs6eKxgfJchKraFn8mmNi/5x2xt0HPmPPWn7G20TzT8KSoNHbw92/8vsyaLn9cPNneIBpGNve5NiFyIcAftezn8uVQo5gkS2uhAv0Ee08qITTrdJjdZteghusMl1OnFa4JxcGiysAODrRncvnD7InRalw4cUJ6leWbehQkbQbU/gaVcy/Z+KcmrEb5yA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1725060269; bh=+bdZnSiTWfBTQ/Dse7BKMdDpT2eaIyM/+d61KXWL3mn=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=piIERoQSiltnDK03my0nB1olBLGauuU6vZzSjBTbMzLXrpbdjexMnKhhAGdS8SmB2MVwQWt9s5LiehtlgDIMICJi7mRcpIlPZVzyAashGdkRpVMNJXh004DHAw2E11TmePesZe6YaoR08jImcGfRsDETLfm5CSS3wmLy+57ubRDIEH4DYL3I6hfGW3nuEh7pxjTdNvB63UiVj+YB1AhaDpAEzh861exNnSZplhQHyfRoAV4s/w7iBq//fqJNIGbcqu4dWfz1MhZHyPSb5SYverSK2/VwWNEoYWmZK7L34sqgjU/iO6NbUGPYnc3KZS6uhT2P68HC1u14EFcPvqMFpQ== X-YMail-OSG: dViGKXIVM1ll2gNejlr1Ca_4j65nQ2OFwGGTkoLR0XjKWcai_5plIZI7FvnvRnB d2ZjDa.a7SteCfhqeydXs9rUrY5RCk1rR8YwVx.HuZ9H1Nnz.P9fA2HFI_6WSKXElHmVYYRn0JrZ Qb_1RsEBKWiOUX2hccpaHFO_JGf1bKjzd5kH.KR3xsNUKVAbxb7H9TIF5mZE.kYfRWz4tiNP5XrW WCvbP9IrcdnRxZPj9KQKRnby8RUPxcC04PtFb0SIAyMuRr1DF_v7zxIXQK6szujQLdjqt4Xfs25p g8FGXxATY5FwJXwkRcTXcsJuvKZM0xW0xetnTTzBuY13wWe6WDyi3X_TPPAyYYDNnAsjU5ZgNWCw lM_nYfxO.07DhIVQ0SF7fT5WMAZu8p96XN1KDwOoPK6w6TC_UbDARGqd3ncpw4nylDO_FemnF5Y4 RQ4GMUu2wlGwx6uq6xSX3K5JEQHQK_EucQQuKKRAMbSgzC9_E7LqcuiMcmqN7NoLC6gL2WzaOW.o z2iXel9nZEey4az31XkGVIRITCWbEFYJ2N5Mfls34Nec2bS_DY56ajNJwsHoxW3IDMsFPd39U4eb pjUMfHgNNQdjW_ahAbwqS0n5hNegt89mmv1WBJvebjb4FXCnfwZv1fhMZmh_h35dWlfy7iao_Rdl u2c8uR6du5V6lRe8Iwq.jV2JkxPF5dJlvJzge0Qje.2gfeX2GXpTzJIIGY_CtQQwm1HfVFwlz6yu zDMGEZEgNE8R3OXvT9zyez6olhkfFQAUak3mhilzrMLb.GkgFiwlA.IDw2p8u7cCA2gfyhPOa0oo XoMYQBJBPR8QXwBU_qVqnOAxb2l5afbM1xBCZHIJKqruCP9Db0t5_XMJeQac13THlz5RGxXGv.hr u9NzJfupk3dESQJbfeiBBwLbxaPygueikqQKBLuDKwPcKe45hdTOW4ypoB5E7RW1vyZu6oYUi9dF C4wQ50OaiH1N8HHKcV75Fh6KWaoO886G4Ah0yEjYGSiUuNTA_0qHh2kIyeDeI23kWLp4Jts6S84E HMIuy3F4prDbp1nMXVbcq5O1ZijUqqThoaGOZ9g_Ip9zNkiZTrggYwmJJs4vQgLRBH7QGb.INpUT mcQctb.C_5SpgchXTtJe3u3sTGj3GkrZQrDAU52F9VFGAJkbGrP0jEKhkueQrXDKqMvSky6LX4BD GMQiwSXdfj3qpBALF9J1rzfyVnHbz3ma7bBD.0.TBghVAj43BT.N83.Ocg3HMGko8xyXN2b0xRGm mHmc1ZGXHKsOF82x_vcf5cUjCneTjOdgXiT4dfJTMrhX9cjdffqMPyTauKOYQd8Y4vHtVUl1YtqD mSnSprOS1JHqv_UFMkAiKS8rq7Zkhw58EQkHtWPC4y5Zzjhjrk5v8CcgkRi8Z1ulVUSK4sVxY1_. iKbxyMf.0deSNcOqFOm0aXvD2o1OXY9n7qwGLekrUUZ5uFTQsFrJC.hH0LiAmf72Wx8GPsmycATm afD9qrn7YVZ4Ypf4lpELqR_q9u1wuyPYUzpvBEwN7vdaycgA6tfUcMBYi.Lghyw.E.xOowyhoz80 nkLvydpnXPRhVZz2WfsMFiLwhFsA3x4RIEB_cYMrZ2EaC.yQ3gbE4cqZIUfOx5Ay3MoOvjXHyyEk U0STM1HQ9qBi1vpKcuf61NVUg_o368EBkUsKTFPoF.oX8oHZQZ2MfkTVWtrJst14WlyOlBGD0pP7 17L0m46H5RYG4vusbi875h.0HSH8sha19xopnNGJtOJYg8yP72pEPcaBLHOXwr5yT81Sn9sxbo2k .eM6OTJPuZp15P0c742haMrbg1yTO1pxdnxNbuOEdFAD0aP6hLrIX5eV3xdznVGDlSfDL98Vj9RN iEqM0QSXo3yWQLcRz7cibggLFfSolma_O5VmkOQZ.O9OhYLCnRrtM4ZO1F3QhFrHVlIeD.8jqx07 yNn_xiHa4Qomgqjdc7D6AB1luRoQU6yRdxUQl2GnQHEht0sPd6Z8YFKsWFV4MWrX_rS1wWU_6lvv KsRBM1BnkUadByXEJ92A9QMcIl1Hz21c_TRIB_us3lLdcSqyCP047EfcS8ujKYPNb1v9dypNxcvQ 2vn9CLpofUCYkGyAEGqzEEWQVfv5ZAgAni856NTxnZjCMRrTFN1VxFSHiwKHHooOPDS_pUfF6r0o _hudT4P6Qji4_rGWwUUbcoNzjNsdwvkn0K4zdkcHsZYuuPxWTKrOEoxbH0nQBOdUjcKy.5RxOBlo dVV1y0hRJAH1jlx5Jj7Imp2tTfzHgys8dpES_b5fJIAi5vLrbyV4HStcD1N4spuQc_X.66XCUfxW gNIwLgIGjypgZUKX3K4BRuvbgwRZOOdNNdBog X-Sonic-MF: X-Sonic-ID: 8f26e9cc-f8cd-4a89-ad5a-294edc51a9ef Received: from sonic.gate.mail.ne1.yahoo.com by sonic306.consmr.mail.gq1.yahoo.com with HTTP; Fri, 30 Aug 2024 23:24:29 +0000 Received: by hermes--production-gq1-5d95dc458-rx7kt (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 65967a7eb546b6b9c7e6d25218f49724; Fri, 30 Aug 2024 23:24:27 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable 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: Building firefox 129.0.2 in armv7 poudriere-devel jail on aarch64 (using llvm17) Message-Id: <75609A57-7B50-40F5-88A8-0278CCCC018B@yahoo.com> Date: Fri, 30 Aug 2024 16:24:15 -0700 To: FreeBSD Mailing List , FreeBSD ARM List X-Mailer: Apple Mail (2.3776.700.51) References: <75609A57-7B50-40F5-88A8-0278CCCC018B.ref@yahoo.com> X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.19 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; NEURAL_HAM_SHORT(-0.19)[-0.187]; MIME_GOOD(-0.10)[text/plain]; FROM_HAS_DN(0.00)[]; TO_DN_ALL(0.00)[]; RCVD_TLS_LAST(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; MIME_TRACE(0.00)[0:+]; ARC_NA(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; FREEMAIL_FROM(0.00)[yahoo.com]; DKIM_TRACE(0.00)[yahoo.com:+]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]; APPLE_MAILER_COMMON(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.68.84:from]; RCVD_IN_DNSWL_NONE(0.00)[98.137.68.84:from] X-Rspamd-Queue-Id: 4WwZ400qyYz3xx5 What my test-of-building got was: No 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 | ^~~~~~~~~~~~ . . . 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) . . . 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) . . . =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) 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 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) But firefox was updated to use: nss>=3D3.103:security/nss to match what = was available. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Sat Aug 31 03:33:07 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 4Wwgb86y7Vz5TSq4 for ; Sat, 31 Aug 2024 03:33:24 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic317-21.consmr.mail.gq1.yahoo.com (sonic317-21.consmr.mail.gq1.yahoo.com [98.137.66.147]) (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 4Wwgb71wStz4Mrc for ; Sat, 31 Aug 2024 03:33:23 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=ByX34mF3; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.66.147 as permitted sender) smtp.mailfrom=marklmi@yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1725075200; bh=TRIYIhZSuKAxTbhvWMLujKrv9mGKlxz5n7m0zsHdXl4=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=ByX34mF3vBFc3+9RfKlI3OlV2uipUVMVkmzrOq1yzHJYEA4B03a3AkToSgX3XpUN1RmDRxjXRbcgkKoZOgx0hogQCcf3AW5x5CSG30biA7aHNlFqx8B/+qscwHwOPKDfKy0Ip6P1zmQx+0pyivC8lx+E7j8K5NpqMpKBEsDWEpks4KDglgGS0sXnFm2dNW1eF/3rXXoFURbXKuV0qOMCyjiRxAb+NBqa0LdQx30hHmeFijMTtA994cNApj7kaZJvFs1YsUREE4YI2b/zjqEMUTR1JxBuERstRQPIi5usEEdqKHBglOMgs6hrtw/wXDYNfhaRpi5lXHXTy0j8JUQWyA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1725075200; bh=4fNk4qwJpUjPDmLW6xg/U5sU1SAaPQonODGb/cxij5O=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=Ap8MbcYbgfmpJiBUIz63VqkbYyJboSYW6xmpPTsPHvnjwCWPPmVROUjjyP7TcbXV4l3NKj7FRJgIPqxArCm5y70A/U6PwZOLWED3X+3/RTVkmQp1ZHGLrrf5RgmL7ax6vTAdj0qRUakuCpVBcHxJHIPllHtIuLeNq5UZUErq0qodyfYAxVBPm15jIBocN61mDW+tvBK2Fwro00R4+0iUyZ8buWNt1ry/VJPyHxEaSGJ3ahA0jeiqyd/KiyVwLKgWVPcf+WwYyIyB9XpznNr6XGP4Bmsj3wK6ZBEH7R05tnXRm2vVoJOd04BOFWh86hJvDcqBhk18lpXYwVpCxfUw3w== X-YMail-OSG: WZPrNq0VM1k48sQWCqznIYkHLZgLP3vnKzLuB3wemGcTGWMRKeB2R1dL_8Sq6Eu mxgxKjuwFWRy19y5CD2liVVRsDmoZSfMyYAfAqPopRTVqnBM7wKgRDSBvgeCHdeaRIOwzZSElpZX GIP_LnBwOK4sbwKhCO_52mOqM4P3ouIX5QCQCQbgH0IR3040SDEzlkLNHrx5GlUiJsrPw_.x_lpQ IC9Qrt0_t5PQ77IzNKQWUjpwv9w4my8kT9Wg2nFHoSMZ2JQ6BztslE.AwZ3ar.T28_aEUi4hs2fh n8ShDwCaUA5mYqLd6CPa02cpAoX7OzfbbJovMDrsm.v8x_YD8_eMMzxNxs9ghUANEyEUfASi1UQ5 cszKNgKH4.67Xg6cjFpZZa9t0q06VmVN.aIuBzxgfAMpPZyTx3AkrUy7ZJng2hE9zeeCdFkU7H9n S4DOQWyJ7zWuK0UvBmjt_qbbqtnN6dQK580s5AeW84YrzijDxVUhd0HWJvBtUdTQon7ZS0PNji.s 1i68i43O_KosSM_ocPIIGGDP8fqY4pA65QmydOrGsdqJ1888kPGsNlyFfXtbKGTMjzjjN9vSutz8 KwPzHPlW5j_NrqA0qx1ci07r1xTZcobF48O56Zaef42hcgYU45r_phbcIUBxKoR_lfmCkPa1xPCm npbCkuqcmSss0T58EeDLe4cuXcJqDu4d2hq23UHPMmXRfHg1DMts8PCt2nBrYK3GA_1pOwnCm8u. eK2zCbTaMfC_fDTG3HUhLeTus9FWMCLWojAnWFBSiSa9ZESFBWxnksj1QhAIx0sDTKAC5ucayEVF zKCKwbj1wO5gENpCuJRXhYy3OwuFoohcrDALtqKaGjHHEdM0GZv8wEcyzsK4QE4fh70K7l00In3b _FdbSK1Tw7pJbH0_5QAg4TzWVXGvOqlemUvKpFju3wQOeCksabJ68ShmWL7TPPEOWQvbWzrhokm4 BOliTnDGppIfg0f.BMX8sp57dwViu19vF4eTS0yYkDH1XzLd9yGWra0cyRzMNZhgw5dTd0k38Fkj C9wQpkRvnOXcA5A.tGOanrUn.RjDvhyaQTHSZldAurj3z4._SsvorA76jMsiNxYyfNO2UxPq1avo TRKOYqmZ3NJ0.RHFhMyjsS0AZs95GReg5R9DDg8Hjc0vXahY6J9QBGfSAZnCZR6WrVuDCaEL7l.e EXxRStcSNgNfpSfhil9yUgfc_JeMKd9HafCtGLhvCA3FXGq07kYNc_mbgVPbP7WLIXbDKQXwVqpv zFvF3wnfExc980NRhFfNwgdNxmQ.uiAmtW4gKTDZad63yHMDTTe4OPG8werRwI7M8AW29A7xfvhy 7F.SO3sv.e5xM_w0xzX9j5KHpT3oABqJL1nTu_TeIT5zoTL379Elm6ha6ucc..fKXi45bQkmocze .E19SPq3A2aIXVCsGmZkFhB0ptI39Q0L8LZfxg1_6sLzHh2ONuP1qAtkzI_1CHLSVq0Jwez.weNI vwNtJqIMPBcH_fiu0S4moKqg54mGZDwQ0E2e6wXz3k1VNwxuKTcmQ218b0ReHePMucWdjYgtZeIZ zCO7sbJlJn20bFIxosrilMBhOazAfs9eBuEo8vvTwjkupUkGs550RQle4vzl6Nm92NUppuSvmIPg K5HOgruVCz2u85hVp9slfh7zyU3zwdl9suGz70fZ0JL0S800BiDlr13W8.gL9HrCnoeafVyqs87L nvv8DAA6tnA96ufUMjt8wGBGxq1V_TxeqM1fkL2wF5iIsiIraskUb2RYQeqMTwwlW6JSivtXt78c I9m93HO7RzFTYMhOD5p.tWkf1TnnyVqotR0Vl2Y1PQ7QBk3lSx8gE53l4qM3knGys6GSF0Wi6zR. z6s3RyBovG7PciFecFoOvEEvZShKefqW4IM_eIbKNLt6Askb1x2JKVqGQMZC_3z0wJ496npUtpP3 Q0VOiJ0jZWQS.4iPJ45w97fTfhboooRxsh2RU.OMkwkZ3mleWtS1DMniNSLAa20wXqubBt5JLIFu 0dktjRiDTrg.H5heCrdrQl9OlXFMFwpOhmVj6mDViB7Sd0fdNN1vGcYswYbGQQcXOYN8om6up_w7 GbhLD01bnlKK6KfXcf5alYVKfz0cYmlFeQpBXlUervM3YXjc_v6HIkGxjpw9Opd7_eTCHsAxe9bT QbPFVSKRik7B9nEyRW5ca2imf6q_chbsBJLXIhp1B.RXG4Pnq_eLfmVKo.DOaJF_7tC4Wt4KVvmq AqLhfJYtsnMaTTK3I4HjA4NNYwkRQxIp1w_GoLX4ed8TuZWXDFBwX02XGoBQloXEcC5F.WlOtHfY aPFp0WsSqjvLhmg3BjrtE_2_EM7L563jWEV8VMfU9Z1B9DA-- X-Sonic-MF: X-Sonic-ID: 1d9f80a3-8063-4569-9546-91ededfb3413 Received: from sonic.gate.mail.ne1.yahoo.com by sonic317.consmr.mail.gq1.yahoo.com with HTTP; Sat, 31 Aug 2024 03:33:20 +0000 Received: by hermes--production-gq1-5d95dc458-m8nfd (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 90dc47ab7f4f918cb12e726602e02909; Sat, 31 Aug 2024 03:33:18 +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: 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: <75609A57-7B50-40F5-88A8-0278CCCC018B@yahoo.com> Date: Fri, 30 Aug 2024 20:33:07 -0700 Cc: FreeBSD Toolchain , Brooks Davis , Tomoaki AOKI Content-Transfer-Encoding: quoted-printable Message-Id: References: <75609A57-7B50-40F5-88A8-0278CCCC018B@yahoo.com> To: FreeBSD Mailing List , FreeBSD ARM List X-Mailer: Apple Mail (2.3776.700.51) X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.98 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.98)[-0.983]; 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]; FROM_HAS_DN(0.00)[]; TO_DN_ALL(0.00)[]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; DKIM_TRACE(0.00)[yahoo.com:+]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.66.147:from]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]; APPLE_MAILER_COMMON(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.66.147:from]; RCPT_COUNT_FIVE(0.00)[5] X-Rspamd-Queue-Id: 4Wwgb71wStz4Mrc [Subject was retitled.] On Aug 30, 2024, at 16:24, Mark Millard wrote: > 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. 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=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 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=3D778e212f2= 34a825c5e19612df4be2e8f838cb024 doing: -_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 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. 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). =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Sat Aug 31 04:26:52 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 4WwhnD2btcz5TXxD for ; Sat, 31 Aug 2024 04:27:12 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic301-20.consmr.mail.gq1.yahoo.com (sonic301-20.consmr.mail.gq1.yahoo.com [98.137.64.146]) (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 4WwhnC2JW6z4RQv for ; Sat, 31 Aug 2024 04:27:11 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=TXskJZ1N; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.146 as permitted sender) smtp.mailfrom=marklmi@yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1725078428; bh=VKk+duoNpZKw1bpP1nDVIVYFK+U58zbFypTLkmePogo=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=TXskJZ1NqdP+hR07iI64DDSZ8K5dfd9teBgtmyklJePeJphcUPoGK+LhVR9gwWNTm1OHg7MzL0dHSAnT5xtvhhkEkhD56J03i4LTf162+Xr2XGiuT5V4793NRJxtC1MCKfShxy2H4cNYyF0qiAFR8c1aPOZ3lKM2JnFaLVElV9DDuZzl49+cUGvCxtIrrdk0VtVGJMhh8l2aMAbrz4ty320mXc4K4wlMH1iHFRGe394H09pvcM95hW1EbOQpGrq42XULod4AoTnJcYfaBqiRx858VEQ0GScp90eBOgW+XpObn1oVzkfYIOX7PNchkY//tDMFBhsMVFoY4ijOFzm0AA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1725078428; bh=KG9Bwjk8ihNc113yPbwgJnL9V0S7+A+7f645IGN+UKp=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=sZ50yZENFi1V6iGGVS87b9FKg6CipxvzqNRKd+GIKXod5jSfHaBPVwIa1mGi5u7qO3a6E3WxdjJP59Qu0Xtv8Dq6zm7VBSpMBcvW1QTyMZFNFkhqUMf9DOPySYKXsBuqwDHZ9jpgvvLYlMLhXQb5gICL4K64qTF+aQbo+b38OY3NK8BBtK+gEcHXi0MnIr51vNzXbRAKncgrl5aBLsaPAu1kFz1t141GTBaKNCYy5DwRtXgf1c3GPWrpAEx3F9G5OLC72K5yzgpc9AHTwDc/AkAv9fKaaSxhzq7hMu6pN/IkCk7de+u5hZ4jHBH7U+nOWbMaeFHABmVtPKaFtxN9BA== X-YMail-OSG: zoHFAzoVM1nMfOFGGdTeePC_e2doO.CwbFxP3tlyO3uaIm57Tn.pyDS3QqPh4HB fcgdCw8AONqwk3ui02egyG.WLKmLSgJqGdu66Kq7cGGZljmSfCxIo0FhvWNb1IhUmNZpu8iDG.iS Z8wGW8AqSFzS790s60VeGMfXrOngYUjDP2pxLhwY1hwbEOOS0PBA2jSOyjdRTui0Cl8D76jX_9yc YOaGue3A.Wrxfr1YRUJA65w2DeO78NjMPcF5DXAQn3TfdOuntkdMdQV1AeWPoC37s7LEI_bN2znw RtEDyGkA5Y.lajMTYoNmiAq7wBo9r1ZdHQJ0DNBoZqBCUC6YNt5lCdoguGL.3E4e80NEhMngaJCG fIcq.DB3Z.fMMo8jVqUHDMOw9HjYGemN5Wwz48Nm2.CR7TT5TKMXU4FXfA2sSmvIksCbwbVbOXbx OkBffo0CPX7kTPshQ1V3Mj.P2cEV4_GTL8ArkQpjpEG6dVqBv.XPZORk1ULRfb.waNXJX9cyHHnC uwLw6K0dSoUnQCJ5zIaTrxnOQXATLduJsZWJLvZPILRsuQHL7V_4yzNQPpcUOGTE2grGbcuqgeeF 2L6W1q6Sg7leFJoF8DUt.AFHTOeKuKgqZY347nQh8ldDXKkv2Q8yWkM6SjxgqcpOQnD_vOYHq36E Nv4RYXzXsoNsJNo8wB4X.8I9v2WvXOmkF94GJHeBid9J6veClDo0SlhGWzpbyGvCO3aYPE7Xsz4p 8dVm4ONmjL5KUXUqcYI4GvpjHfSPF0LHq5.QY3PEmTHX2E.e8tRfJ58qGPlWHNv9KcTL7MfDn9zT vazWCZ.3X8s26079HTRuxavPH5dZupLSyoQDwzccUXSf7fAGKXvKKkw64pC02w5xNBDaltqT6gEA g3zcDGrc9OmZ20Q4TFLlSlp.Er.x17IESt0k_g2VHN_S28DT033a8rHs5kjg4lZ8t9zn.6vbbdGq rKCwv9ddlg1V.lmVqIt1z.ciQbc05Vyc98TyixC.2lvt8hMdNfTxELQ0nTd2VEYyT9.yIwompy3T gWcKyRvWyEzSPxxeo7LHhmFZOPFVwxZc5lqSkm9aVbw_2nvejKC2YdRSrCl_50iw0cdBAt5xwH4t MW2Mz2cqNhyDuQxzWsHNMn1yvEbnKKYf6WVtPTqdFrBp_nEVZgwo1sq197QsdEBn6XsS9MtNxBre pWLkWSu73OZnDPAE55V86U0_i8fffRSSl7EXg1EJRcySTuFkCDX.QUAugU6Kk_FjJWs.Ats.fbtQ kmLlaN8UB8pwfU0LCnq5CcVUyCa9.sGTcidk_uk9xLloBLYqJe1WYLR8MoYar.QIXpvI72RGrxmT NntmCnvQ03XVwDGO98f5gmeB.rFZGKyoqA1tV3iCSzS8B5EAdBxqWwsLfy1Qs07.Y5OTgsnqPj4M hyD_g8EkL7NyOYFcVgnP92SYAB6nJJJEZKGDqkb8qgh8jCuQvZo088vywBQnmsDBJ_RPHWUlGV9B O_ZDCXer_BnAL5UveTFD9ZK0t4SoP7T8N.vfo3XJVpCShG8It1IoYdBEiKeaWwsvaNw6OdX4iTZ. CoMcx6jTDfmIhYO4gRUx6WeRP3wuAiqfK3fwGHh6fLuDcFQMYkHS7qrbDEJs78qNrwAqRdS0Wj8u OVCnQHjZ0QscrOv2dsdLWpuNI2xTcgmPAcG0rBf5nkIgL3GWlDKYbAt2kpI3LXPr5q50OC03eltJ p91RwzIdR2eCimFDl8CKPBvu1_2ReNJCtVukZ9SaVIYGGVAP1Wpq9AiWjF2lVtOAa0Qn0FINCqm0 WNY7aJfzpG_Uw75SHe74kour6Qb7VS6.QZum2nlE6AAxtDDbHGvpzAzMq07qgt_RaSVugnjr3Hs7 f2wa3Uuyb2pwwhToUDFw5GuaRjAHkQBSXBR3ZHJln25ikOGeA8gjf37S7idPhj8tLLqIlnpDuS_t Rwlbw0g8jdNb55qw4aMYZWEbMr1PV9g3s0CZ0yP9E1NhaZCaRr8h0BxZq19USB1H6LmpTyIq.QRk PEcpB_QrO6Cbgd7KRcNJaS_1REa8q0xFaaDNmqbCLbWE7R1ggpZghvttN8cHasROb.qKip.X9gK8 eO34Rn8A7OzEQf7B3ZF4TNP28mZPsiAO2X2R5TEGwzheH_6bynMiIDWNZkNIMFQbZn9LjrDbs7Iy 0fKl9cx9Kz.11ysiaM5ixBaDfOSQi5NwQQrTL0ZRpYwfn_ZVYVMWKHcc7IJEofgW0LIW0MVPIXqX oWu9tnIVlKHuEWXadCwzTksYlqHaaBzxTGmW.q9mZyQhG1D38L7_ymOdCEp4ryWS6UdfGJ_stolF oBmW7eIoNd1.bymXXdj64Yof5tR6Js1UIqMY2Ne.xx98- X-Sonic-MF: X-Sonic-ID: 7106d25a-51d7-4523-a18c-e55e40866be3 Received: from sonic.gate.mail.ne1.yahoo.com by sonic301.consmr.mail.gq1.yahoo.com with HTTP; Sat, 31 Aug 2024 04:27:08 +0000 Received: by hermes--production-gq1-5d95dc458-dxlpk (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 4ee841cef428eb37e074dc6ecf0793b5; Sat, 31 Aug 2024 04:27:03 +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: Fri, 30 Aug 2024 21:26:52 -0700 Cc: FreeBSD Toolchain , Brooks Davis , Tomoaki AOKI Content-Transfer-Encoding: quoted-printable Message-Id: References: <75609A57-7B50-40F5-88A8-0278CCCC018B@yahoo.com> To: FreeBSD Mailing List , FreeBSD ARM List X-Mailer: Apple Mail (2.3776.700.51) X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.88 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.88)[-0.883]; 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]; FROM_HAS_DN(0.00)[]; TO_DN_ALL(0.00)[]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; DKIM_TRACE(0.00)[yahoo.com:+]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.64.146:from]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]; APPLE_MAILER_COMMON(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.64.146:from]; RCPT_COUNT_FIVE(0.00)[5] X-Rspamd-Queue-Id: 4WwhnC2JW6z4RQv On Aug 30, 2024, at 20:33, Mark Millard wrote: > [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. 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.) > 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 =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Sat Aug 31 05:05:06 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 4WwjdJ2ZWgz5TbtW for ; Sat, 31 Aug 2024 05:05:24 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic305-19.consmr.mail.gq1.yahoo.com (sonic305-19.consmr.mail.gq1.yahoo.com [98.137.64.82]) (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 4WwjdG53dcz4Vs3 for ; Sat, 31 Aug 2024 05:05:22 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=BJFnB8hM; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.82 as permitted sender) smtp.mailfrom=marklmi@yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1725080720; bh=wnJMmm/OgpfPWGN9AkGP62LEoJXQb11f8T7p8WDh/Yo=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=BJFnB8hMzyJ36CMhVd7S7DyeLMWIuLC1NqQXS+X7YrBoHd3LOa+na19E9SqTDnvIcdrqtASX3D+juAtmT9xdHXyZ76FSPvQ2PQamqMbrKzaaf7Dgjf2YRJxf+u1hysyqkg/3ssCggdFJQ+H41zFL9Qj92O4P2bq5+qu6MhHSYwtEqG/UQP9loIu7WLBl6BCXuLUj4NIXcITiTBTp/ijxxuumzyDTFdkvUe+0mx8l2UEiE9wRP9WJJueFGW0TOUs9XPw+kqpiPMAPdo/5q5yo2+WyCCbT1BQhcYPt03T4GrXxlrYkXUr3Vq4T+kOZo4CT3XiHrwhfwDdNEzlMT+n3jg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1725080720; bh=APeuQRfBHqqiBCJQK54t1DTYh76z/wb2K8EheiJ1eed=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=IWl+Y+hvcq4Hm5Zr+plAq2IHmvE2YWefVwHzghHB2qhrTSnLj2pwsekHyQWMb+uIlUkS2h7gWNs5E4iJE+jzKTRTfK7CcmT07O/FAJmAPRsbJYmtLNBsmgRGlHo4fmfkiuGqtJxgBf2W55JTGqhPu30CnyjXm55p0OXScPdDhrIwLkV7aaFW/xQTffiQFCN0wMbaxLO0tMqZ3QzJROF6LPJw2WXlO1tmw2YY24LdPXzJ8hkYTl7Zl+bwzWydI3pOMQEZmvI4s/BlyAoUuZd1DephRY5YOjcDt44Os+NN6MNXz63oUZUMCLnHUDCFPESNPl/3KjHN0XrMuRICU5Po4w== X-YMail-OSG: jDij.d4VM1niSlc..nb_2br_z1HC9OuSUz5BZxyr0Yssd.O.iRGcTVaj3dcWnt_ Oh3VrU3So1BP1T3QFBLdG3qNuKGs0Hf6uQaK0EXPckRMrSLEWKOvQhuwR2tGnTxrD_0H4dnfN6uo 6Qgz8JOiSIoASd_6R0RRBwj0qsEWFfy3jZj70Lj0qp0.fItL8opMc4m7aeyZKVA9oJykyTw0UerO U513BvwoMYAqlT6OFQcz2KFrVYG38Pp9JFPBD_Z6E8Ei0rd9EMKw_Adf6ImS.hJYaDItbitMx3WK sKYFadKdtwZYOaMkwcgH2vsrAo.2xlOInHp8uTh42iONxOQDDcDejmztKCbMWXeNG9oxexm0Y2L9 n4dEviSuG7oRRYn91_f0ysIzEpJjxVoyzy9Pg0uGhV6_p5w42vOVoEsN2sMchmnB0FV_aYrXNC8x 0btnQgNjHOSJGUA8JeHqWtWMN2j7Ex3sWURNvblrCN4fnZb261S.bF7d.ypA1Nvv7ercfOWrNJ.r pgX09d1I3aEZnbulndi62nIHGhIISuzEhAS_soaDFwgxuu2Jag3J1vJp2YMt8kN9GTuqi5ITJQ0m p4K2c9o1IqHK7Wb_1ZFHM5oGsmg81ax6CG4Ua.qcGyx4l7tEeiRTpz7Z2RJgKGnDOcOfz7K3ZCRd TgCGXbP4G8KDgOtkPfTJ.DD6B853UIPliUswpVyh5xv42CGZAGaCkAIRu.hkL8RiUMNp2UqodMZa 0bRy4yGyyt9N4OwWuGMLVtbPL_CeBN8twFapckHP_LNZqDtvZvJdUHyuqoLx4SmCAQMj_0qq0BiX rS4U7BC7xR2cJGJMczVWTzsGb6PnbQ5dyPX5gj4y5l09uJ32xl5arjt7oN2KyIvt6PXDZaiixaGp u2HbnPDln2MdPh917uNrEVZvQerosYlLdwR7if5M5eauuMm8d8fZJlLB5rWHL0hyRydm3H8ioh5m 9el7JZ59rusU_hqJvdSOcxX01qVBC6OYJemWNlIu.QwH3bcIKDiPKOpk7r2aQYieZlPqNY2VHKvi ATSVVBBs_9amLo7mKRfR8CIaaoWT7v1t0JpZku4ThgQwOt1MPSC_EdbVi4cUdppsL2uoep1k.0I5 43rGyvUOOt7DXhXKPl46Mirn6LHM7UW0yAMzhD2YF.6qd5QIOZzflGD3mueKXZLxIVdxFBnUU4Kd XTsPR5Of2DC4U6T8EBGczNQeVzzydY8.XMfyNvzQwVEOFheSvCbSNM2nz_tUee0se_CTM3t8zd_y iqs4ikcrw_9VAHrZGnhzHv7vyngQOtW_0levAWKwXnZizbPAwYRQjxAIbhaF4JMEVUybh2O3Ojl3 L3Akb9oxn2lp_3LiMIbKtOftbsh53P9mOTRhJe_F2Vrd8zoQjMxlcQLX9LgxTzzbkLsV2aFGd0Tt LyeXwxmfOwHHwAqQTSvGw14GN8E0EzqjMm_dXFvvF35QxSqynU9kvKkpmmb0Isk6rg00LXJ6Bn78 2aH5APN4QXUNAkeKi62t13cFVNMxNW0aHtitUz0E2W4CtbS7f7xbcerXK32Gz8BHhHuKHL9OpETZ WGgFH.uNxtgRSjPsYrAQxzPS2xTuS0LQ1FW5UddEOvu4S6vkquEWvle429KumddR95ehmliZgeAg TcJEeINP9mS.mheZHH.EyW_tQvg6ZNWgRSWbiYVTHII4jX2Ymyqpf1NQdYmjjMqOHe_XZ1XC4fvX 0ub_DPNpS2DgkrcCJaHA6IGcZOXQlRxuGR93W_I9pGW9P2Z.aQ.Q5zyYDLfxDvuqBiGqkobKcPX. CS2xstSvKS6SfzpU58NjNv_hYNX2RPkaHsDQAOfGcyU8Nm21IhNXKZHmaqkUmK4f4uVZwBNtZgBY OV3zUQ1OfzQVTjkgNiQB84sz.ujpV0VuhsrU85628Uj8lKJSIld4jwnCoC2wCb3Uv9iVGp_JbXLO EaYWWE4A6y9pSXyS5Y_RS15zpcowUbR_hSd1VQM_5IpaB9q4rQhr.u5wXL05zCbU00olwrYGbd_a 7x7ieoeeEOT5J2CC2a0o.pHigY3iU4.btLKolC5xZFueO5yZHPmx4ywCrNxZlVm7SZq6BvsQ.vPd hWQvscV.RDKuNTK.s5UM9Cwj.XQjSAoHxEIsZw.7wPR6zN6vecv95ziV3T7mTH6aTvTcHW071TNf pxyn7A202ohpmk557l9SrQgvPeg5fVMg2L2HbDjDcgBBRP0O6wTrBeX9wtTCMhJGUXGmJ7mbL4Xk ChZJr0HMZJx34BCchWW.CnxX9ytcStojSZjLb1C9L_nehN9B3k_tfV1M0jTisadvLChso4dTCg.I TTUFlvB78SIIELHpDyI4VRjVldEhSUQ7YqPJynb7Y5Q6BlJo- X-Sonic-MF: X-Sonic-ID: babf24ac-4270-4c36-bf8c-946d40ea0cd4 Received: from sonic.gate.mail.ne1.yahoo.com by sonic305.consmr.mail.gq1.yahoo.com with HTTP; Sat, 31 Aug 2024 05:05:20 +0000 Received: by hermes--production-gq1-5d95dc458-b574z (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID a48c938e75bb8d2de92244db149046be; Sat, 31 Aug 2024 05:05:17 +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: Fri, 30 Aug 2024 22:05:06 -0700 Cc: FreeBSD Toolchain , Brooks Davis , Tomoaki AOKI Content-Transfer-Encoding: quoted-printable Message-Id: References: <75609A57-7B50-40F5-88A8-0278CCCC018B@yahoo.com> To: FreeBSD Mailing List , FreeBSD ARM List X-Mailer: Apple Mail (2.3776.700.51) X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.88 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.88)[-0.884]; 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]; FROM_HAS_DN(0.00)[]; TO_DN_ALL(0.00)[]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; DKIM_TRACE(0.00)[yahoo.com:+]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.64.82:from]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]; APPLE_MAILER_COMMON(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.64.82:from]; RCPT_COUNT_FIVE(0.00)[5] X-Rspamd-Queue-Id: 4WwjdG53dcz4Vs3 On Aug 30, 2024, at 21:26, Mark Millard wrote: > 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.) 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). >>=20 >=20 =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Sat Aug 31 06:29:41 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 4WwlVs046vz5Thq3 for ; Sat, 31 Aug 2024 06:29:56 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic312-25.consmr.mail.gq1.yahoo.com (sonic312-25.consmr.mail.gq1.yahoo.com [98.137.69.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 4WwlVq5jlmz4cPm for ; Sat, 31 Aug 2024 06:29:55 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=fNyhEiKS; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.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=1725085793; bh=yFhJM/49Ko0Yn9zKhh8Wg9Rs4NpkIRAFo7hNVnSVM/I=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=fNyhEiKSAovKkIfwn0nhNF/mQLiUcbHgeFE5aKxrERE0tgzJ+g6bGYo4sgItANVLsLsVc5qDOtyEVvJmUBOdIJCqZz457t2Mx9SYNl1A6vVco5Xq2LxNRKAMMwlL05t6Ij+KSFIViHB6S81ioTW739xccHntUeZcrCnsfZt3AV26FUN6MNOrO3U5Qeqa3GzS7mUMQPwAjX+N+TZrKMyMCMl8Exf5O33PTRFRDbtPMUJFCLt+ov7yPL6JLzwRhsjz800lQPs0xbxWuulUA0gzBUM5qis+Kwkdlllw3qF9ujpHcZat0iofQzQVWav87+YImx7y3lelFV000sm5KbW90A== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1725085793; bh=fYRcPIJx2TudAaiPpwz0g9QhzNG7fWyVjo2mSJp+3Qa=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=UVMCsRFsPEXEH1m1cWIM0s2R1GkcMoGLe+llhNgJZ05MG24Z2Bu5S3meK3VV9m3fpldSB1oOE9QSLOy/+ewhvtsLj8UsIkZy4BayUwYkSFuxHnPOZNZ8Ghva7Whf/nRH7QESmxyeNpb1wuKluaPaIqNvp1QsjkLW8sjEocU1Rcw9AR5rnSHcAc+rEXJdP5CbgXdk7l8tV20vkr/FObG05t/NgW/wjMc8vZ3tA20XwZPhuBHzddybEUs8pHIKkdcn4JykRlnZarcf6Sdc/8rw54WZOvbn+/+4uAIjMbpd8HBxEcm7x0HmfJoSsFxZ1kCxgAXIq3OYerVg3E2Dg8L5xA== X-YMail-OSG: iIg5w_wVM1lmxfegFm3BrEWRbROG254H6gzjXunrTIfBMhG6xvPEUZ8P443.7zp UGn6uJq5nXr64S5cWZilAss05xM_tPHM_mLFtMPfEPnI3RBkTqnDNR.luFD_l3OC5B.2bzPclUkE Pq3RECaF5wA4iENLqBEMVXukxagPyij1NixP84nHlAnwbXsgCtzrVSp1YUE0B0A_WvKSofJXMWGp 3gyC0r8zoT3n1Xwatj9W_x5Gh_xAZxRqsDe3sp.sLSrL.nAQC_8udxjNHu5gXbNNfCrp4u4dB9w8 SdrzSxkzTzrZHrW.TGJUMV8ISmzxtVRnmTl5fNEdSV5eNGhRzv3DKCwsFKpjOtd.sazAkiiqYkcL pE32vIYQd4HMg9sC3YEL0BJHJTNza5NPkCqmD0aWoN5AdtbtugB5v43kb5KPxbsfZn1xoc1orPK3 G5pdmzQ.aCHzXN.8oD50YtFg56QKWIN4nqOzgPNLNrNw.Ie3Ex5.fX8olT7YE_hyTl4pJULeVABZ L4YKfZyRLdVfB7cYhbfCjL7SlkUgG8duUuD8qcf.Tk7TpgiuWzt85r7YegaLDUygVzmit58Xhy9n FTdqRgASs2F_VhW4T8CkkQkRXXp15kdqPWM0ae6w._GQLiUJQeWNbhBPom3MpIRKl4jJ7VBL7wzi oPWSL_frs4iq6rG2LPvqVnvneqx6dLOsOOm7AWG.TEJHM0JI2AV46OVRjfW0vrgyX2GpKWgB8vYP Z9kOxl3_JuejKwQztBVMsavSjY9MXbiZiZ2g_FyfMoJZ3xliNnzEMbuf6FwPrzYV7TtzpcoaBw77 Kezvy6XOnDuz3lYIvu7AgmVubKcjWD_fkxlgdU31uqEGjpcgpyxz.WdJ2FVUVuC1DBEYF88JXD88 d5ogkV2IGe8wEu8Y4uq45vCVtcLw2GLtHW6FKIHcSc5foQKtdFW_ErD4Zt_A.VVQpWM0Jg4HxILR kkWShYfvYFzBygIyESG1BKDk5CjVsuFkujbIKNd8EVm1jRkqlKYqHv4ZDd6aiFObrlMQfwJl8J8J aoYjaGT4..7aHoHO4SVDqVixjZgkClFa8yFNsM6he8IqQd3vHKKzqRpb2KLt_2AVTwa_CKlbyxJ4 2deZQvmomlGDoDnVyzDW1nVXdceVHk8tOybgnUR2twMWkae0u4Lzf.gneBBCRg7CoZPMfHnFEmkq nhfP76y3PTjH_HDIJG9WhmiS0MNfmzrfPRUmsqChh2X1oroqyBx2Tod9.30_91OLol3I3tQNEOrE 4B1hp4XSwpDD5wwhdmZV9GxsdWrFjO7huGgar.Z5gYqhiiR0pdW5n1G0BkhNih2bqkTJWrKEYUHe WRBPHhnOC3mnCqC_YBt4bIjGFrRauF0elxUoLIPLly2FBw.b0x1_Qi5J9i4PLDHaF4_z8J0iBUyS QXMTJCHy1a9dDv2gtxcI0zGwx1LGbVvKas1GfCmE17qJi.4Evr8erCX2H94xgD7ww4gGidFhYHgu D56RQrlFWW_6tEqVX4GGyKd7xW8EFT5pPK4Vbn_AvFAHf0f4xWa_8XJ0KvS2CWaF8icxbWSm2raq s1KYosG9G6MZ6JcllFolMdxlr169GSUAHK44TT77XepoEDAWCZT7CRAh74DXNLL1hEgDZvigiHpa 1ZIPO6acWZZZmQiVG8ylfWbwGdYQhWh3P0Y32LgFW2HdJriqo1bJ2ci7Scx8pN.0U4AQNL5e9BDB _Zh4GGaJjdVOCXdXUC4yQIwnu6QR_yM2W4DRr961GHMbIlhoagQ4NpFihZnwVfMiLykbFVFUiTMu 73DEawkUxa6jABClDo8odsJcQOpUvLxgMF60Y33DDsEv6_xDtljJC0StlDLMtO0_VRwUiB8TW6Pz nynrmfhHaN8JgSMU5Q0lfz0qQwq28.s9eFLCet8CMPHxrp2JAe7Dr2VVyAd8PN3o4_YNYuM4xyNU E5RtQ.DtbfhpfnyEnPXJLY2R_VF0.1PzAkCnSYWqw8P2h1vlQULOe525APO9sCKEuxOrCYyuxbzJ qGcX.0xaDnK4HMxLX5_nBcSYqL9vrIVJ6luWHqeRqcBapg7VRyf_B_pCUKpLO2npOjmO76tfqrlk B8Rva_FCOn.2NgCJDgbEOUM89SziWZgH2Iceqk2z51mZmel4HUx.eHG3IUyt0jmD0hymTpumbwFy g5_AJX1e7SlFSLn..JOrc6uu0j2HTmTqpTTgJkd49JxXFwUp131g_Yd7F.h525qpcRioUZEBbbus EKbAzrBNoVUy8aooYFYxdi.QCtcSSI75sZDz0s9b1gkAUogTikaG.E0UUsEqx X-Sonic-MF: X-Sonic-ID: c0da4511-f563-4780-a578-314ccec1658a Received: from sonic.gate.mail.ne1.yahoo.com by sonic312.consmr.mail.gq1.yahoo.com with HTTP; Sat, 31 Aug 2024 06:29:53 +0000 Received: by hermes--production-gq1-5d95dc458-6q8w6 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 8883d9e59274279e414ddca33421ea99; Sat, 31 Aug 2024 06:29: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: Fri, 30 Aug 2024 23:29:41 -0700 Cc: FreeBSD Toolchain , Brooks Davis , Tomoaki AOKI Content-Transfer-Encoding: quoted-printable Message-Id: <24D56998-0939-43D0-A98C-E398CCDA0AAA@yahoo.com> References: <75609A57-7B50-40F5-88A8-0278CCCC018B@yahoo.com> To: FreeBSD Mailing List , FreeBSD ARM List X-Mailer: Apple Mail (2.3776.700.51) X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.89 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.89)[-0.889]; 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]; FROM_HAS_DN(0.00)[]; TO_DN_ALL(0.00)[]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; DKIM_TRACE(0.00)[yahoo.com:+]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.69.206:from]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]; APPLE_MAILER_COMMON(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.69.206:from]; RCPT_COUNT_FIVE(0.00)[5] X-Rspamd-Queue-Id: 4WwlVq5jlmz4cPm 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. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Sat Aug 31 07:16:47 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 4WwmXy2Wv4z5TmBp; Sat, 31 Aug 2024 07:16:50 +0000 (UTC) (envelope-from mmel@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R10" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4WwmXy1yK1z4hsC; Sat, 31 Aug 2024 07:16:50 +0000 (UTC) (envelope-from mmel@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1725088610; h=from:from:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=zbSe2hJKwshLEKf0c6MHWRgm8tjhijUsYBLo4eqA3Ko=; b=SoM9gIAAMPul4qDP1skFLcMwzbWpbbw59tQD8RFPsBk4Qg9jxn3RRWXqUHl671r8+aT5qZ FaYmEHBsW0CtO0f88qMunQxgtfsL+PHuYljLrGEaV/QbZzrvvkJGMkQUmO994CtlozRrxm 9w1JIQ7r2aATuO+qymeo5hpbawyh69N2KN+FwL1Ogd4xcanOMA5uZJ8YY0Vps4IItIKpHD 1/3R+AnNLPl0nSiC2QEFNgssQgKQW5OjtXxboFQXPGDvd6Yb8ZlNYwZ7FP6vd2V/HN1sRp MPfIRgaS1Kkxt+ymQmXhkSkzNJygYLpCrkRyGAw4RspwT+hayUfBj868weyNcQ== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1725088610; a=rsa-sha256; cv=none; b=GM4yVmmy7AtJN48T40HhZg7WPoBITqwFKPF9l+yHK69XBJrF6J0E6kCMdzAtkh+WB+rfAa rRbW+L+HqUNGAbzztcviDvyWLcj3mGZAcbUrTRC0Sq4wYl/0FgJx4uwhp+HWVyzSqtXDX8 +3QYuacJ6zVnDiaIujiEtdYpZsKjklS26lGumeZNY1XZOWOrzC7/escGWDBp1TSqY84Xh2 Gj0ucRab+C95gJBaJSlA52L+vi7hBKxuA48fpzX0AyFEhwkVCKQyRAJx8vjoG9SJmFlGS8 pfq8CSAyMJQmssW6gMKxTun1mc6W11bEhwkEWFsggRIaTCtyJk201/82Shv3jQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1725088610; h=from:from:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=zbSe2hJKwshLEKf0c6MHWRgm8tjhijUsYBLo4eqA3Ko=; b=mAkKaNXMDKiQN7jou3gh3tOOYAqhjKQ3F9D6mVM6+PZqs3fVwa7e2FK3tRBK96FeQsgAtd IN4CaG4Fw/dlUpmeQG9EUwYiAEw7H/oOu8zKinjJ1MmGxiVWiL+vo3M2wDyapo7N6L1FnX zrIcprcSpBzc8AsqfSfymBJ8BfAAmBj0fLrG/b44wB6XyxD3LijiGMLBh0kMBCelGIxlhZ 6PwEi5f9d3bOHOUBD+jIQ3YNC+55d6Ddpi5Dpxw1ufg5zT095En8Q8ycl682L+1WgJbhsb gdgDfc45EF7Gmt0Flv40prkm+UfD9trFW4LOoMFir3FEMxnl2jIfJ0+k53Bbog== Received: from [IPV6:2001:67c:14a0:5fe0:686e:135e:76e3:3f4e] (unknown [IPv6:2001:67c:14a0:5fe0:686e:135e:76e3:3f4e]) (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) (Authenticated sender: mmel/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4WwmXx2vZcz1SW1; Sat, 31 Aug 2024 07:16:49 +0000 (UTC) (envelope-from mmel@FreeBSD.org) Message-ID: <71a16edd-94e7-4a06-9a34-59f17c442a96@FreeBSD.org> Date: Sat, 31 Aug 2024 09:16:47 +0200 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 User-Agent: Mozilla Thunderbird Reply-To: mmel@FreeBSD.org 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] To: Mark Millard , FreeBSD Mailing List , FreeBSD ARM List Cc: FreeBSD Toolchain , Brooks Davis , Tomoaki AOKI References: <75609A57-7B50-40F5-88A8-0278CCCC018B@yahoo.com> <24D56998-0939-43D0-A98C-E398CCDA0AAA@yahoo.com> Content-Language: cs, en-US From: Michal Meloun In-Reply-To: <24D56998-0939-43D0-A98C-E398CCDA0AAA@yahoo.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit 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: >> >>> On Aug 30, 2024, at 20:33, Mark Millard wrote: >>> >>>> [Subject was retitled.] >>>> >>>> On Aug 30, 2024, at 16:24, Mark Millard wrote: >>>> >>>>> What my test-of-building got was: No 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 >>>>> | ^~~~~~~~~~~~ >>>>> . . . >>>>> >>>>> 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 >>>>> 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) >>>>> >>>>> 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 >>>> /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= 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. Michal From nobody Sat Aug 31 17:43:06 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 4Wx2Rv4XjDz5MmFT for ; Sat, 31 Aug 2024 17:43:23 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic317-20.consmr.mail.gq1.yahoo.com (sonic317-20.consmr.mail.gq1.yahoo.com [98.137.66.146]) (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 4Wx2Rv1sm7z4SGD for ; Sat, 31 Aug 2024 17:43:23 +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=1725126200; bh=UWErIHNtXIRF0nCZ6L/pJOn6hvaqSWSpIfCGERlyGkI=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=frhqNViSaJoHyf4cmKQ7WIS0BWgjPS70YyRjwU1FFTWeYhPbDIyZRIcaSxkd8wrDc2fqyR2WovJHFOM7kfcYEisDDljZGBr/bVWapn02Wv0WCIZl1m8fWktzRYJWAUyvZ77Q1BpaBCJq3lzh28iKAGXUDwAungzJlhqw6+vkCbCinHLdlpiujc2cqJJG1/ksxWKJrTCWhRegWoOKSBXYPrvelPblrmfzzvxZhBqlZENH/KtOLXLHZJL7y0E3QXX1ud0x754wGGPtwa2f7YLmSJf7hidzZ2AWHxujqYGa+nnRFqih/YpcLT+ChBu3NHvbmCKo3RhwsVCeqlB36r+ucw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1725126200; bh=Xp3ZczZpxy215q4PR/HG6LbqSbH1Oqu4QbPk+Miz3Im=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=N/ZxBz0BgQMbmMBTBV+f+YsISC76G6EjTMzgIg60QFlgpoau2/bGLwXwcNsbL3LJALl33BgiR4hyGa9PLqK8D2mJf1u4dG1jvkO7VAKFKes8udY6XD/Y/5Uz8LZ4hZZ4a5fIqA7RqTpiOWykWcuhW7gzM2EkVlpEWShhUIVFvnJ8K32KFYwZcQENQRuBDmAbNrKrnVX8cSH9rb9McZBvE8xqE+69OqWrlXMGKx1Zeh1yMxw7etMP4Ve/RXuixqm0KkczS6MO8Og6o2w5qoY+dJ15in94JjDRmIljCvr56SslkVnzkys+4//J+neUBuX1WBwzk83/ZzcTTWWjiN8JtA== X-YMail-OSG: AewTWqwVM1mhqUKP8SUXscvru2rXRmpRaBner5oOVr.yvfyixcvVkFbGVtKHXYM 1nDwzCjMvCh.jtA34AvI1jkvsE_.K28j7SXENhtJKR8J5ct9MvhYR80Y9cMWy_mOw7MeUvJXPTQJ f2JhZmMx7aKLygJDy0Ecwcqyi.3YlU94KM8PQ9YqU0tsxOgrv.mWAPnjRK1.uTHuYhl01E2VEHhr 14ADaEQiH37nzyHitsMXkdOArwaAjkYS6ZgT8rti4VL6odDR38garJf8fqRyHBT4eBD6d8VvqHiZ i.zDMVU3UWlk9b4lnAkOKhmkZwPnfWyCcgGUUr4PoWFPTgE03sgxhu0PzsNiWQrNTXR385NEHsYM JOeyjAQwtpzlwyTKBZUIrjgoDE_t5ogxkXHG5FTfEirc3f.QtFDymXllc5ubSWEXJJUC0RGptvWK hRPHVwK1jJdR37TCGEQ4BKs.saSSkGVacioeb2eNeVGXAXSI0zeAg6AY9YxQo9Xa92okY4YIRuJ9 wugR2Tw0JtuyptiogCj3oDMg1RwJGTauirjARoS9gir8R6P6ucYE.CfQoK0L3pyOHOOYDTKNdGaH cs_jyMGfhArueiZ9uTL4m1hDNTPMolurMhlajmbXprino_4Izu6mUyA3V12MzVN5e_fqOx7DfqAY ygvGAN5NmdXVuqZhK3FowaFeprCsXv2XvjQe9pU0KtzVZoj0Jz4BYXDUoAFkVSDvpR.frcPN.0Uf WnzpKKABfrLLyqQTQ.53XdUEgMAvozrJ0GAFleoOtNN0vQesLmYtSIaG_LSmSvmoqyFLKy2_BNHF tw.kwdf1MghcRPvFvG891vlqRAPUrS6mfP0JhWrIwho9DVeIwjATem_vL.4eRGaGdo.Ioi2D1pzP xv36F7GmhvH_l_.GnTGZeXzodkMSbmaaxK8oOIukhkIZQqHbqnaV50Qh7onv.mEHCMS6fMnJj_in BAWiS3rMcAvzgF3ywj_VcvF8wVc.YS7nK_eKUjwlY4OGrG9kKoOuv220Ad43w6Z8qL9mpY0H4o8f S.FU.UUyno4bX..pw9IKaPXX1nEK8L7Yc26LJXbNgraqI2Mn4XdmRenmbE6yRls7JKjzrvwvZFGe bA0PNRpQloPb64k5tuE27dXy.e68KMjEoC1ILUlDbFC7CZMGyQb3gZFgF3eFCSF_RD.bILyoE3DS KRQcAqbvE.7r5JIiEgn0plZ3S01CQnZlpSyU9xCcQvgneFgowLSAaNcUR0VOThFho7dxzl.g3iVd JP08L3yEgBjSvtETVs5og212k5BbtML7VYGPpYIoXt9pWXTG6qEbytG1DY9AW0sg4S_Leu4E9AVF Hjqfo6vq8bvzNk9bcXD6Hx7.sWHiXElz98FK2bZdsN8gmP4xGaBjt2OXPf1XykBBsfnnkOlmyCbm p_fw1n_.Rz_frn9QIjjJ.nBYm4UZTJsu_VDNmzCjkfJfoa5OvR4QB_kpiw4coFhE6414zplA2qUm KObTydH3r46iKfoHa1uA94peIz2hgBO7B_z5yWqO4rY.ZYcivWbpEHPldSZOv.o6GKy9X4FO.q4p BREDXytFj1I6iRbHnj7tOV9nnOyY_8RSsSYxrPdcrmXeigJ985dxabFmB9fQiae9DGPrAdYLvoS4 8NHyOGo3XWtlyx.5oedo73g68izU0Xve09CtJVnu4EC2wZ0IrT27ZJjqiazoXkltTsuG6whHSWoL ADwjBsx7xTdqnecCUKia7MLo.8qfUcKTajafVesBXSxUe_hvqg_bUeUouIu4v15nh3ix611lKgCU o_6VWy_fcr3XWKdY0OzgwEQql5d0ZtgvNUTZNLlArldfTqvqTqyGDHWzrKk_qKey22tRWoe2NMMs 2t9dUN062w3i8cJYTT1YsGx1SZHiGHMR2cSPsVDLEYW4Gh7IaOvzbUV9F4y75xd.z3mrdGHyr4.I cPa7YIblvNWgdoM7Csx5aXHWsEqUTN9GHdnjo5.o.aACz9.mhPlBBUc5XYM6FfrbhaQ89Wu49Qk6 N2hMscvHrolxvFHzWDkZVxzCVJCfV49BfS9alUULYdV.tfNcNjF_W4WE4nF53vXsKldF4n5OKajH AZywrMc_7zhH91hV_ino.IQE5gkcY3Y9ZjzalpssWd.sQ6PrMLsw1PW8dUaoTiCxHT_yK6YJRqzq 1UC30dpd16aTUGmciOGBHtxEd7kAW8mJwKkTja1ePYfdYwJVzy2uXLScUPpEu49PdlYlgYnftsS8 hBMTS3CsRgYuZ0WoXIgX4XOdYEyxYWuMkO6800aA3OkaVgopuRP20VZ0IO3NPoFQ7nkeCIa3S4jU tMp2s1.y6cBpm4zGtTIqwwCrYwIiLSzuwkMkcKb0ziyJu9GQ- X-Sonic-MF: X-Sonic-ID: 1851c1ca-05c8-4897-8b29-a76850338684 Received: from sonic.gate.mail.ne1.yahoo.com by sonic317.consmr.mail.gq1.yahoo.com with HTTP; Sat, 31 Aug 2024 17:43:20 +0000 Received: by hermes--production-gq1-5d95dc458-5n5gs (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID b32315c11689c559c0d6a891fd9d2fac; Sat, 31 Aug 2024 17:43:16 +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: <71a16edd-94e7-4a06-9a34-59f17c442a96@FreeBSD.org> Date: Sat, 31 Aug 2024 10:43:06 -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> To: "mmel@freebsd.org" 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: 4Wx2Rv1sm7z4SGD On Aug 31, 2024, at 00:16, Michal Meloun wrote: > 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. 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 =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); } 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. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Sat Aug 31 18:29:45 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 4Wx3Tm07jvz5MqVl for ; Sat, 31 Aug 2024 18:30:04 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic312-24.consmr.mail.gq1.yahoo.com (sonic312-24.consmr.mail.gq1.yahoo.com [98.137.69.205]) (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 4Wx3Tk33ZYz4X8c for ; Sat, 31 Aug 2024 18:30:02 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=mecMTg5Z; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.205 as permitted sender) smtp.mailfrom=marklmi@yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1725129000; bh=vXX0ko3sP4BYjNu9DZ7aNv5EwGzrf331BqPdVIZX8Hk=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=mecMTg5Z6C2RJ9OthmlNWrOcLUUbC3wPt5AR+vfG8Uptx5CY1aklewok8MK9Ki6RdRfNjsqMnHV1CKKOa88pMb0BluGLhlm5yft6m1LmJNlo2h2OABrYnUaC2kbAVWtwBcQIln8sIgfV/EpoMOGnxiUUtY3sX1efjY0/ewBZuT2r8eVzZo8AfsPKWzL5IBdTAvKggl4n9PjgcAjOYwmvKHWTo6VX9tQOyr3khO0WZd4Ozp/CVewpnBND0UDIDk5ZOYvhW29LrcMVqKxelG/uJnzdKBaPhN8Pam8a+J3nWkXO54ZC8jB93puDEVUgE3CTHDoproJcTeqrTrLTb6DECg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1725129000; bh=h8uKY5vCYQa22kqnoDDSA3EykCmNhWj1fggQV15stzb=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=KF9GYv3KJlf4O0dNp/jEW7C1mp0VbCeJjitNRp481UBprLW0tMtpb6jplaHreNTljy0RZPUNO0HZX4kY01jjDavJYTSeeTKaMrU4u++ESGNXev0k/OgTe3pBHE4El8+b2DdWvvVwpYD0cnbtMkFrjPHlPzQ2srVDbNzXjED0caFkoElss+V+Htm3cO0Z8OFzU4JUDU7WhUBxV8LfxLCiLvrcNRMv4lxG/yr6b+KoNeFX5IeNiNqRk5w+3c/qJ6X5K8WnGiVGAxM24Ur6aLlULcSMX78xlWw/tB2OzR7imbWFgCxbIaYLJ7o/pVdk5ZxOONfqLIZ/FjB7D3Xwqn4JcQ== X-YMail-OSG: zfCSjSoVM1mySkttFCx0A378dT8JBmOChJdWOQyNHVBel8pvquNBhgFS722f5Ra NWHOH6aVCRmzgGbkDY85JYMv1G5e8Ze8pHllOWJwuo5UOfkIpI9q3RB0733zPI8Uhs7RaYmmBvPV gNYtuV_VJiJuJu4dMS3R0a3paqcd0bcGP11_nVJTOQ0rB7Bot7BHTNoaKOdiGoN1znayojiyFONS GE12_e8s8V84gvIUXfV0A6tedc3avNGVPf7urBi.DK.VT8APYCdXrNkeSZLzBWHLEcrOlg8ee3QA OsrNidDnco1py9s9ljgjPUEQWsFDcyQM_AY_FC0HjPhmQU46_2GjgD0RqRvzDXUqq47XI4eEQn5b U4XeRZCSTZOCr2uCQ1qaflPaA7A_R1vPD0zYuFnvBkzCy3j7FQicIBXlVF5hJsV7VsK5UM90B7Bc 2MruevoGa3xGQ.e9Ac2tPr9RUhQgICFy8SOq5k1OPjgyBfaB4bwM.OW5x9auufBeqmRaycepx3O9 BTMoW_SUJnaBmDXAHtnTkTU5J91iiB82hRdhMISQ.PTelYZThxa2GFjiJgbcD7e3uJYqjV0p927u XIQyTAGs4HO.CTZ.FYg4ehjWVmK8K2XAOm4pABfbp_0pcaf2DxCJ7wgxY1CXQJPz0O0XACILqGqP AfgljDSrzI.59RsfutPper2QP5bNnz3qiqz7RH172yaHlunQW_LkJ0Kj9pq9T3KO8AhaZm._.ncu SUwW3LI.g8jeqI4n56.a9_UT4Y_Rjc7v.dvxTArtzK.WSsGmU1eIlQ3vrJaeA2Dnu_k565PqeIEI HnRwfo8rB4GDKNz0MRVVucXmcfOWnTEHr4bwmiQnyvIM2NfiWo5mu7aDojKj6xJh4ffJR0iJUkVr sapZv9fWWKCZUFerffnOIL2RWna73sHoXuu05d4yxgL9doPEvjBrkT2yjRfqWqikAWg6s.GnY__0 rfFTJQiZfe1bbAoA5RtfxDeDf2H.n9GZnZ9.RYIACQUfYccoWT4JyLrpn6QLDYXjtmP4ZVb2r3k0 HNH156s6XWMFGmbN8uV1qH7QyyCcHAq5bCl8rO8mO0cK_seItgeL5P02YWb2NkunIOWyie7xnu43 yYlE_r35k.LyoLpC1vEUrXan3TinYK03alHwZK5XLEnqA9qZsoEP3c7sgqQo8kUOr91EpSQ3wWHu bcqfy_vjjXpYVORNhBQNsjdZeWwsaqr.M7tFnM0v6_xdsmtnh0mEtosncBk1kMgE7uAKKj2tQXNb 2iOa.6sU8TCxOQPK3mLTU4S3CSMgcpow5sYhgUwxKXur8_HWVxIIUdvM_9Dl9w.BEctDnskjU3Af s1LXTxmgePq1Xa4drKTgxuxCTg2z_JXLSiKsz4RxlFoaVlQ1nVmML6Ntq3JKftCveG7EaH06MuQE jljBIAaw.o74chmaeSoCrkc2pm0IAeoCdSX5upzcuZXaCt1x3BR.gUezxe70MU5TLPqVdkGCgjNR Nqs4kHKIAGOO8yUfc427UBqqE5T3oITmj5tBHFwS9h5n6NX3kH5vlwqiLq6Nxo8_07eG8.baUdub 3iIAP6iZj_tWhCetun50I0Xh2oMNwdFJh_fFcSmhyWNIz0COlCHribrsbthbLZmEZy5MNLDDDHfO HaGiqsuYQ.QRYTYI0c28IlOeLU0TTel0li694FBeBO.EKKeZyESW2Df9EOKsmnYfzuZokvCjmGe9 ORCxPr5nB54v8bxFk9pjMHqEzX6gcihPqVsITxO0Gkh2BSoO_SmsvAb4S.oh.x32_xyZ9J1xR2N0 vVyXezD8mBUCuCS53dAi8rGxHBnXlyz7EsZdXoQgQRkGysdfR3P8ShI9iMJ0jYLdD7nZRxauyWwK p9_VKad8eifV3bwMTGS6vchNp7j2ZL6PC1x6usvs9RalmXlZzrPhyk9KfhBJF3K0tXLXuS7Epyji SM2mxUf0mpuW.bSh2sMCHiAaeXLBznx7IwfvaRvVp7FPbeFo1rKJNa8_N5sDSI.XX9qizlwAa8rH Yd4zL8zZNDluH5za58tGuRLChKIxhLNXZk9_OmPnXwnczLGvW5s31lz297xXfEjodVPN_xBbe9Mi gu8xvhPv3g_mB2R5Zvp2.aTWFZp.Ioyh33mmi51Yf3DMV1hGA.jgVOUMaQdFuRy29_KWaA9ndd6M 84WJwmhD_5seYVh.rWlal4M6QBEnhNyx0u5YYC4Zu.XEnJqUdenbmC5kZtg4HmuWaIWJXrQV21XG OUXrsHd0NDWD.iYVLy21KYJplrX8vvVsdt.wz4moZpSa7NZKG_uiD3SGTY1X3CmMEkYMVY0j0UO5 26moL.2kS_Un3v_H5GYi.gNYdHu6p X-Sonic-MF: X-Sonic-ID: de0a0a92-219a-4f18-8ddb-53feabb986eb Received: from sonic.gate.mail.ne1.yahoo.com by sonic312.consmr.mail.gq1.yahoo.com with HTTP; Sat, 31 Aug 2024 18:30:00 +0000 Received: by hermes--production-gq1-5d95dc458-rx7kt (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 5fd4ee56c878e6a3300a2e85e7a4b440; Sat, 31 Aug 2024 18:29:56 +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 11:29:45 -0700 Cc: FreeBSD Mailing List , FreeBSD ARM List , FreeBSD Toolchain , Brooks Davis , Tomoaki AOKI Content-Transfer-Encoding: quoted-printable Message-Id: <2EC1B62E-7323-467A-992B-CE00491A6E65@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 [-3.98 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.98)[-0.984]; 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.205: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.205:from]; RCPT_COUNT_FIVE(0.00)[6] X-Rspamd-Queue-Id: 4Wx3Tk33ZYz4X8c On Aug 31, 2024, at 10:43, Mark Millard wrote: >> . . . >=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 Well, that was a bad idea: if that had been the issue rust itself would not build because if the patched rustix source code. For now I'm testing building firefox-esr's port, which, being back at 115, instead of the recent 128, does not yet have the code that was being patched. Later I might see if a patched firefox rustix copy will work. =3D=3D=3D Mark Millard marklmi at yahoo.com 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 From nobody Sat Aug 31 21:59:00 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 4Wx87B4N4Xz5PdYp 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 4Wx8792xxxz4r7c 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 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: <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-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.206:from]; RCPT_COUNT_FIVE(0.00)[6] X-Rspamd-Queue-Id: 4Wx8792xxxz4r7c 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 From nobody Sun Sep 1 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 From nobody Sun Sep 1 05:43:46 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 4WxLRT5m9Jz5Msgy for ; Sun, 01 Sep 2024 05:44:05 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic314-21.consmr.mail.gq1.yahoo.com (sonic314-21.consmr.mail.gq1.yahoo.com [98.137.69.84]) (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 4WxLRS5X8cz4cS3 for ; Sun, 1 Sep 2024 05:44:04 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b="o9dcLfz/"; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.84 as permitted sender) smtp.mailfrom=marklmi@yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1725169442; bh=3Wbp9O1Wy/EV2jmg7EBpyvgiOsqXMWt0cvtA8ScbEDs=; h=From:Subject:Date:Cc:To:References:From:Subject:Reply-To; b=o9dcLfz/jnAbC0RPi+S9QHv90/ZNIxGhE2JsZVZZCiLm2Cn3qaYs3pOWZ0+k7zd1imdBDXN0KZ6jPitoUj/oI2hmbEZboZXqwz0nBKNQqQapp8MQFE+n0JENaQxFBHuSg+0coOkDA8o9mpVS8yWib3iWUFsNGQ049powj1Xq1WyIcBqj3NuCbyBYdU0SdXlfnnx5YteyElxZFOXHqYih5kxQ6kgN4C2rLcrzo3rV7Mbp9QGWGH87z0Ox4vcLQ52nB0+NC8vtk7hYhbNv1zud2q2WJx9VICXgaVN7b/owYAG1AeFAnFw7I62bvwntDD8RXmKlsy7FXNajjVlA2pqGIw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1725169442; bh=0uEBAYKrUkoSAIlHzw0VL+OcWocNI/Y9D4y24i1p99K=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=dqL+yxB8zPA4Etx9WPIc4ujsz8qAUxWEhUg6Lkho86NyzCb5HKaQoVb8O0ungyOC7EntHhP9SRPk2QZgV86t5PYd4G095Wg/89egUQMcFIffPZHRDGKRVAGmIKwHuidGbCfwqsZJxWLI0xJr2irSSTHeiIALTCIVs8tOXVJbM71TjgapOV7tHYhlN8Uc6FEWnkapANq9UKSd5CEwV+g+AqELb8iyz6QsYKIjEMXqn3RozgjNEvhNeuUXBKAcHgEutErQexarUWPm2jTjmzvG3rsnrxGbAXIZ8xKOxY39D8Lu+Xf6/jHkX7SP7IecyVRGF5SNynUOcm4LXi1hfOiV/g== X-YMail-OSG: yaaw22sVM1nwypadFWbDbXVjV5bOCzRbAf9uZtqdLVzEYDiQuGJoZiIZi4X_D0y KNLO.l63gN6zqmTS9U6VNCmPJ35Au2v0XUCnFpxuDszAgnjhPO9wU81QEIk4fIWGuAXmn6ecEBZI 4J2Qv9I3rKMNqNNV0qWr59Y3sdCmO14UsOvRxIqHHUdMD2ohFw9XZr0pA4uekz7.F8iPjJ09dgZE WI8w3ggwsy4xq2yCZEK8XV6yZLIm.kbZdmwNS0gNPYBFKhCqwoNJ1_A4xCgiZqwpzrM0RM_cEQLY wi3NU6VgRAUjv02iNkPJHWpHRS5HvyBRhuG.cCx.sGXIWyurwgTknQ1MkmaKE9y9TEm02OsJElen DT8l6SSqwHAHrYdN83oeyDO9rGGmBz_oT2SB6lAbqCo18WcSQw7Y8fW8NDR9neeVin3X1CwUJzx8 b2p7gln.aKxg4WbTVql6vttYqVJnVQ.Stv1GLaPYq_YJ._61qjZikC3XUfp4K29rBAOSIyo2a6.7 ksY9v8S.pAna4.BOuUk.gjpZfyYv8.1_T5Zd2wOnaZpViyeXuIwYuXG0BLcQIoYb1AIqQep1v_vQ ZyTdpgDgixKTwOCitKxxHRl9B3SjejaWRxlRBuSzlXTszAaFmLLM.umORrXDpyYYgI3QDnZDIfqB u4rG4M6QlbcuPR2aMEDTBlUFFDpWu_R6U1nVSjhiSh5N38y470qKpLotFNtGl2twtollVZTM3PKN NrisU._JE89U2aHfv9yKZIYN4w6JQgn8i5iPbEX5_4IEdKN5s_r90.XTX97qCQ7EQaqqb1AsMh5v gIv9te2KZnlXLccL9HVvmIy9UP1_.3LIUcsuwMvf582jP62Bhn7P7jiQV9cq3iAOpvMcTuZyFCnp QmL3jOg2SgKk1u7cbgT3esOR5mGiulfgv9zxoqk6CEOPhxNN88Cwgxdw9Gt53f1cAiF3z.VSb4pb 4Lyj3WBF.wf.dWL._jGzTMSMjPW.7_xt37qZa2Mt4KxQ3qC9WX9PYhU.8LWhyxmcQ77ISGo_TTug 8Eu8_.H5n6pokLLnztR2qutk8lNNuZRgi2nhBLA5x1VDIzwnglkV216OsXhrBlbZ_PbEymPVNZK6 wkVEqjYzISu5ha1kNoSELtFlgrW0CGRtMWEI.MttQGY3EvFEd7WE9HuymhlxyDwuOqo8A6UehnOK gg8OccyXDuSn9qXDPD97QiaHkGgYPRmBF3g2lgV4NpCLoiIWR6JzjVZC7x0PYqVOzcPDL7WuudOG aEJsAqE9fg4mLUNOr63BuXFxBpTJnX6I09tluVuE55c_Wg0LieN_YWADSbvY32rusU0k6dToJdro HIIg89kSt2Ci5TCKxZKeKLp5S8c2OV9iDkGnf2HtjjYIZ5X7S8HX.SU4xRPbQ5ySFPFuCva7wQZb gih5UpvISipykplIbBdSWEIfnrZCXGPRGB1cXALz3lawU3KXUt.3QejI.AJFkDzvqNOdhN2HkFm3 010EgouDSkXT3QsXE6E6Uxix9DKWtDui3g.A5Ldgu4vt.AuJS473TpxECuWpjRvsBRJQDhr7NcL0 69W7vFLdsiD.iAk7pNTPgsDGnjw2MbBNnM7L.Q2Sjh1EmszxeYLYERkJl94fBYztI6XzZz0h82hU bDPAY.j7obP_BF.CjI7MabRftFB5itL29L0eG2iHP1AXRjMCh9mo_8vPWKB.Add06TrWXlxNrc9K CW_7z3BwPjqCet3G.HT1NjinR7nk_HDofFHgpdIiUStZkOhzdNs0NiGG4uqIiff9WeIninnUMKVb cWYTTWe4agalv.NK3IAN21lSoWf8H3acg9k6qCb1kNYiCiSEM.pdZm5E5PPDkPBnt0Z42eIkgPRV XA96dcRP1Offd.jUA5jTtHkHjB9G9_It3bD33OkOS02BMHLgYCO0suIqUVnNxbXvfsJgYcJoSgVc QgJIgCxscoG84aW3KsFXHuyJTExC0N6PA92.ORtDKzdAvGPEN1YaKpDoe6kRmzMaq6qBioOZfqbI btvZxYh7DppL4RscZNKpAAWvo0DVLLHN475htouuot_vMCMWixHOuKpnGwxPuu1k2XQsCAVJyrly q2cYpNyQKUrVKGPOGEff5mqNoA2eIs9YFKA112i6cS9_nvzN4j6uxrC5r6cPHE0Kjxb4xx0fghg8 ArpKHfsxYzK5ovqXmTtdnQYz3YPK0.gOqgYVnN20697L.5hxvuhPME8l8uhKoBCCJnmagFVe9gap UtZuJnvdupxqpqD1dZTTu_gk25Pq5kEx65yjNCLZiOBxJcPTjdxPastqbjZGfzYQ0N3GNX5_kxp4 j3fkkLh4LMxvERQty2T9i_zwuUwD4DxW3MQAiKYr5Wg-- X-Sonic-MF: X-Sonic-ID: 50fe3df1-d4eb-45bc-933f-6a1d612842b2 Received: from sonic.gate.mail.ne1.yahoo.com by sonic314.consmr.mail.gq1.yahoo.com with HTTP; Sun, 1 Sep 2024 05:44:02 +0000 Received: by hermes--production-gq1-5d95dc458-5j27b (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 106fe769a15a9721ed3d19f753bdb398; Sun, 01 Sep 2024 05:43:58 +0000 (UTC) From: Mark Millard Content-Type: multipart/alternative; boundary="Apple-Mail=_927BC71B-ABF0-4177-B643-CE22FCE81045" 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: Does https://www.freebsd.org/platforms/ need an update for armv6? Message-Id: <3F73BC2D-41FA-4667-834B-8D5B49ACD428@yahoo.com> Date: Sat, 31 Aug 2024 22:43:46 -0700 Cc: Philip Paeps , Antoine Brodin To: FreeBSD ARM List , Warner Losh X-Mailer: Apple Mail (2.3776.700.51) References: <3F73BC2D-41FA-4667-834B-8D5B49ACD428.ref@yahoo.com> X-Spamd-Bar: - X-Spamd-Result: default: False [-2.00 / 15.00]; URI_COUNT_ODD(1.00)[9]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.998]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; TO_DN_ALL(0.00)[]; RCVD_TLS_LAST(0.00)[]; FROM_HAS_DN(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ARC_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; FREEMAIL_FROM(0.00)[yahoo.com]; DKIM_TRACE(0.00)[yahoo.com:+]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RCVD_IN_DNSWL_NONE(0.00)[98.137.69.84:from]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; 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.84:from]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim] X-Rspamd-Queue-Id: 4WxLRS5X8cz4cS3 --Apple-Mail=_927BC71B-ABF0-4177-B643-CE22FCE81045 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I CC'd Philip Paeps and Antoine Brodin because the answers for the below probably dictate the handling of the armv6 (qemu based) jails on various beefy*'s being deletion vs. updating-the-worlds for during next round of updates. (Why update or keep jails that are not being used?) https://www.freebsd.org/platforms/ indicates that armv6 is "Tier 2" in = the "13.x" column. But armv6's most recent package building attempt of any kind was for 132releng-armv6-quarterly on beefy8 starting at Thu, 05 Oct 2023 02:37:41 GMT. (It crashed.) There are no attempted armv6 or later builds for 13.3+ RELEASE builds after that. (I only see public information published by the machines.) Even "21.2.4 Unsupported Architectures" ( https://docs.freebsd.org/en/articles/committers-guide/#archs ) says: "Note that ports support should remain as long as the platform is = supported in a branch supported by ports." armv6 no longer does so for 13.3+ (supposed Tier 2) or 14.0+ (supposed Tier 3). I'd expect that the evidence against qemu based support being sufficient = for building armv6 package reliably --or being likely to in any sort of = timely manor-- is probably sufficient justification for official = reclassification, even if stable/13 and stable/14 system builds for tinderbox are still = operational for armv6. May be this note is appropriate for freebsd-arch@freebsd.org = too/instead? Side notes: I'll note that I'm not referencing armv7 here. I expect that the = problems in recent months for the ampere2 based main-armv7-default package-build activity will prove to have been fixed at the next round of updating the world version in each of the armv7 jails on ampere2. A bug was found and fixed for this for main (avoiding recursive locking) and the armv7 jails = look like they will soon be updated. As I understand, these jail updates are normally Antoine Brodin related activity. =3D=3D=3D Mark Millard marklmi at yahoo.com --Apple-Mail=_927BC71B-ABF0-4177-B643-CE22FCE81045 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
I CC'd Philip = Paeps and Antoine Brodin because the answers for = the
below probably dictate the handling of the armv6 = (qemu based) jails
on various beefy*'s being deletion = vs. updating-the-worlds for during
next round of = updates. (Why update or keep jails that are not = being
used?)

https://www.freebsd.org/platfo= rms/ indicates that armv6 is "Tier 2" in the
"13.x" = column.

But armv6's most recent package = building attempt of any kind was for
132releng-armv6-quarterly = on beefy8 starting at Thu, 05 Oct = 2023
02:37:41 GMT. (It = crashed.) There are no attempted armv6 or later builds
for = 13.3+ RELEASE builds after that.  (I only see public = information
published by the = machines.)

Even "21.2.4 Unsupported = Architectures"

"Note that ports support should remain as = long as the platform is supported
in a branch supported by = ports."

armv6 no longer does so for 13.3+ = (supposed Tier 2) or 14.0+ (supposed
Tier = 3).

I'd expect that the evidence against qemu = based support being sufficient for
building armv6 package = reliably --or being likely to in any sort of timely
manor-- is = probably sufficient justification for official reclassification, = even
if stable/13 and stable/14 system builds for tinderbox = are still operational
for armv6.

May = be this note is appropriate for freebsd-arch@freebsd.org = ;too/instead?


Side = notes:

I'll note that I'm not referencing armv7 = here. I expect that the problems in
recent months for the = ampere2 based main-armv7-default package-build
activity will = prove to have been fixed at the next round of updating = the
world version in each of the armv7 jails on ampere2. A bug = was found and
fixed for this for main (avoiding recursive = locking) and the armv7 jails look
like they will soon be = updated. As I understand, these jail updates = are
normally Antoine Brodin related = activity.

=3D=3D=3D
Mark = Millard
marklmi at = yahoo.com

= --Apple-Mail=_927BC71B-ABF0-4177-B643-CE22FCE81045-- From nobody Sun Sep 1 12:14:28 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 4WxW6H0VCkz5V7Jg for ; Sun, 01 Sep 2024 12:14:47 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic315-54.consmr.mail.gq1.yahoo.com (sonic315-54.consmr.mail.gq1.yahoo.com [98.137.65.30]) (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 4WxW6G20Kgz4Brx for ; Sun, 1 Sep 2024 12:14:46 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=YKbG+nUD; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.30 as permitted sender) smtp.mailfrom=marklmi@yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1725192884; bh=Gdag6juG0N7BJ4i8Bp5ef8FIqvkzHuhF9nQYtKtov8A=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=YKbG+nUD7NOQh0I6UHiAOIUUTKuaOVT4pQu6WtbNaK3JuH6VpEdRRCbzlhgZBMCw+anjfymkQEm0PXFyDltatC/YrDAdWNKcpU4TJS6WxvCXFwbpxrzBOAQy7/paHj3Knb4nnliSMDGp0VR/lv4o5QdNLcOav10bohyWBDeWd8Ey28dGzvpGmnUX3LbgxP/is4NGZRw3N7LiDeV7mf70EFToUDT5fWzZh47n2LJIDsDUJ7lDRc7oilhgNPonVA61+Hckxr8L5fBraLjXmN4O20H5zT674qg36NyKIoNoU+ikezs/l5VjrMlY0nCEgr3UW9l+fDNY8E3s9OvGS5AxBw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1725192884; bh=pZG/T6g8u3+eOuCgmLlSBRSy876GwdbOTzTLSn+zFVp=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=XUhUPXhJsuCFkJ6UiaOtgn32FVsFDT8kPX8yu1/53w/3WHkirQTTRzs9Mn1X0p3Ps7eJks6z7WTyx6n3VriArN8aNd4jpznYN4OpUHMbLbM/Zng+VH1ndTQa2f/R23N4NK4+XkdIAEiPZwbU46bGujjFgEhse5jDrKmgbDBrAyCjf5hKNIHPfHG22vq0Vc/Ro2thg51k7RlbIb555coEgjc6r+OX7UIhN68/fF0FWrqsg9WO+Dn/we+yZoK2XZQEcTS5Ymp7Dx+tfztsK0e2tDL3LNa+45U2P3bcOw2kB3gXmmbX7uU0lWF1AI37T/Rk0+2rzrXPBMPaZPAL5MFmdg== X-YMail-OSG: eykhicAVM1m7076j26EWG.dhmyGTSg9Xt1mwMw9NKUuP.mslmYlylvmyWzrO9wZ FmAh_PzBcGNovCJz4Hsqx0HGbxSrHGS12OHZgOZA7KtMzgjrDHtCnamzg8t1TjQmODKc15kT9hfM dNb3v1adK2.3Oe3FIhXsS.pGW1_tabkmtGDMLQgzzcZSb4MzZqVsREhltP8ZTYbRfR6a81T5iuoN HRbmPB3nZMICNor7Y4IyijAES3Txr_HoVvPTE2YaS8CTjb8EnTGzKvbuQb_agfG6tF04Mz4gDsbK SwfQ8WmtVtOaoS2u3u3YOu.PcF95veJh42F3G6I1jEBKzw.sQAfs5QaRXZWzKMMbKv._NNSCx_DB aZEuXqQmp9ikx0q84d20D_tZe7aR4n6iJhWhLvMEph5s2e6o3f7.w72QYeqe22s8vAz96xj.M2hj 4DKTdyF83DLMQcgp_L_ZUIymdGCghf6rLTI5jvceD.O7hadxOPirj67pjhA8a7nwTBSeTkTBzpvo .DPfCwnFhEkUbD4s6hPiKhEUnkD6KIo9ae35eZ1a9ZyzGcqqciysqbtHDo2MuP2sHSC9IasEulTM Qti.o23vpip07fvj.H7loAQJMT1DHPAhDLKdvrge0Do2H3hGYh_f72spM.EKs_oHOeciHuAQyJ9W cCKW3KXCNab2XHPhpQW7VQhPPES5w6WPvTtywUIclvK19xwse41zlxBm71qHYsPTU1iXyO3mOpkm 2dB7WmUlBQF2UpiUGp9qScVj6Jcy.KCyA7zlTJgwUtaNFoFldmKXgBqB6kqCUvBFtPjk9f.Ip0rA 2XM4XcCOGwpPFtpI5qo5rlDOWrIBSkBe1mJr1s_cTXdBETEjOQpvyNfT5krcp0PAJQmrDAzssBwN mKNdb4D_8_MgJXLsLo3q4rp6UCjfv8R47DVAASOr8zNUCKQumoMbL4Zb2izMFlnDjTsQAUj2OMmN HlTnzT1MOnrFg3LjB7oTAMOMryhXmmSq5lnocvmsVLarE.0icakKuZ73iZuGgVsWAaniTwopyghc ORTEkNsFJHpK9xeA5MT5st5RAlpDAuMINIRHH5oXQR3R_Bf7N10q2MBqF.2EQAOvwzRP7OMyHPDE Mhjl9wF80MO0pBZuuo0rDYB6Iw4Jp2.Kvz66RCPTtN6nQElg9ISIYtxtxxjMkTCT7erZBVzIVjxX 2Ha.mxYrup24kGQcFVGvEADElOTtXUQdyPczbtkC.4v7bt5ZLaU270ucJWKFW7wAL61MtrbGGd2F haD8L.Kb1TWDybgdzbI_bOhxJPCQqHYHptgL3oYCkXOs77DJa7q.EiX.KSZTR107HM0UylVZnTfm m5UiSaH9i44DqE8FrFNIugFwzMUh6oK9jbnx2ywtBHV.nVKiekx0.YhZ_fNBWXcpaaOPEvbpk1rP NU_HseOx2ffmrIQxgds3dM0upMuMOjueWBZW7h0O64VjI3BpmaKwsd_vTqITUQmY.UvR4aZ78JFT uQRwRlUwzoQlTFrZawhAv5rlEOpzeoq4TeMwKqpS8Ro7QslYsXw4zc3NYrMee2OFMvh837yv2FBH kdO9QkSJUFHFiLWQGs353WJqvygH8HNO0fOmuOj4ED5yItYNlSxiwmTCcpd.CsBgAbcqK8glYrsx u1tGrG_qOGKrWgjm.l7z5LCOMALIhFeotqlRFw94fVXH0YTDLaWZqkInn6.mXLtiyoXrLuFfemxJ AEp35IFAeuI9GYZH63t798zBCM2QqblonXUE0zFUgaypaIBiSRtoBzvPuyAhxMEm4hE.ooBzUV2c dd2ZlT.vNNgeOcBOQgQ8JQftzrCQCpEXFLVXeFr3bgQAtFj2xpUEjaH91BxeFtnfik23tVh0guY0 Y9dsBNRhROXjuzZbJnBB_KhXPAsi0ZJDV60c0RDjdWQR.bheYcP6upQnIg4SdIgbLS68D0a0vi5w lKAqBdEvl9G1WWIwDGgetyuPqtBfA8PX9nei_B8e3I5qGm3aHqSopalMzLRhqpLB3tRzCXAlkUzl AibPQ9ueWWZqk._Rhez6E.M5QO3iubfX1UB2vBZ3mdBH_9K4FkBAXmeObcuq0DbvBo1ETIfey1o7 QBQSo05DvvGNlmXpDsXhkv_1wBypEsGRqmCqEjk0LqjDHVj5MOGcTAauJuIXf197_4ZQTBvP2Dy1 cwDfpl9AkUWTmJMRI_WHnpn6EwQeCuIR8eG.K9poUYTpULxkdJa2oNKGDQ7dVAIo_N6NQ5rw2XI6 LbR7NrxXYVO_1J7s9RYh4Y8LrFKEzQLR5VyaR21cqDqiFUqEmagZBJFv8BV64LP3fOStLR3eDgqH BK2FzO0Q8wqM2qXF9fhDIz.C8.g-- X-Sonic-MF: X-Sonic-ID: c3e5356c-fbb5-4bdc-8b2b-99a12c223c16 Received: from sonic.gate.mail.ne1.yahoo.com by sonic315.consmr.mail.gq1.yahoo.com with HTTP; Sun, 1 Sep 2024 12:14:44 +0000 Received: by hermes--production-gq1-5d95dc458-7jxgc (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 057c76932015d74674b033e6b3d9d5f1; Sun, 01 Sep 2024 12:14:39 +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: Does https://www.freebsd.org/platforms/ need an update for armv6? From: Mark Millard In-Reply-To: <3F73BC2D-41FA-4667-834B-8D5B49ACD428@yahoo.com> Date: Sun, 1 Sep 2024 05:14:28 -0700 Cc: Philip Paeps , Antoine Brodin Content-Transfer-Encoding: quoted-printable Message-Id: References: <3F73BC2D-41FA-4667-834B-8D5B49ACD428@yahoo.com> To: FreeBSD ARM List , Warner Losh X-Mailer: Apple Mail (2.3776.700.51) X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.84 / 15.00]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.84)[-0.835]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; MIME_GOOD(-0.10)[text/plain]; DKIM_TRACE(0.00)[yahoo.com:+]; TO_DN_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; RCVD_TLS_LAST(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MIME_TRACE(0.00)[0:+]; RCPT_COUNT_THREE(0.00)[4]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.65.30:from]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]; APPLE_MAILER_COMMON(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.65.30:from]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim] X-Rspamd-Queue-Id: 4WxW6G20Kgz4Brx On Aug 31, 2024, at 22:43, Mark Millard wrote: > I CC'd Philip Paeps and Antoine Brodin because the answers for the > below probably dictate the handling of the armv6 (qemu based) jails > on various beefy*'s being deletion vs. updating-the-worlds for during > next round of updates. (Why update or keep jails that are not being > used?) >=20 > https://www.freebsd.org/platforms/ indicates that armv6 is "Tier 2" in = the > "13.x" column. >=20 > But armv6's most recent package building attempt of any kind was for > 132releng-armv6-quarterly on beefy8 starting at Thu, 05 Oct 2023 > 02:37:41 GMT. (It crashed.) There are no attempted armv6 or later = builds > for 13.3+ RELEASE builds after that. (I only see public information > published by the machines.) >=20 > Even "21.2.4 Unsupported Architectures" > ( https://docs.freebsd.org/en/articles/committers-guide/#archs ) = says: >=20 > "Note that ports support should remain as long as the platform is = supported > in a branch supported by ports." >=20 > armv6 no longer does so for 13.3+ (supposed Tier 2) or 14.0+ (supposed > Tier 3). >=20 > I'd expect that the evidence against qemu based support being = sufficient for > building armv6 package reliably --or being likely to in any sort of = timely > manor-- is probably sufficient justification for official = reclassification, even > if stable/13 and stable/14 system builds for tinderbox are still = operational > for armv6. >=20 > May be this note is appropriate for freebsd-arch@freebsd.org = too/instead? >=20 >=20 > Side notes: >=20 > I'll note that I'm not referencing armv7 here. I expect that the = problems in > recent months for the ampere2 based main-armv7-default package-build > activity will prove to have been fixed at the next round of updating = the > world version in each of the armv7 jails on ampere2. A bug was found = and > fixed for this for main (avoiding recursive locking) and the armv7 = jails look > like they will soon be updated. As I understand, these jail updates = are > normally Antoine Brodin related activity. main-armv7-default on ampere2 started building devel/doxygen and during the build it extracted graphviz and kept going instead of hanging up just after the extraction. It is now well into the build phase. So it looks like FreeBSD armv7 package building and distributing is back to normal after the armv7 jails were updated. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Sun Sep 1 13:16: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 4WxXTy0ZBmz5VCJF for ; Sun, 01 Sep 2024 13:16:54 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic310-20.consmr.mail.gq1.yahoo.com (sonic310-20.consmr.mail.gq1.yahoo.com [98.137.69.146]) (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 4WxXTx21lJz4HbX for ; Sun, 1 Sep 2024 13:16:53 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=jNHTp92g; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.146 as permitted sender) smtp.mailfrom=marklmi@yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1725196610; bh=l5M643phfOhiNDqRZpjXy4RV4fanqnONoQ/0Og0yuug=; h=From:Subject:Date:To:References:From:Subject:Reply-To; b=jNHTp92g7PTA1glD1wUvCeLSWikcq8r47zWJove9lxchbH5xhJraV/30IyAsLtVyB3LYIl2vnyC6lE3Qz1pjnejdBK7h1f/wWNFT55b0KVIDlm2T6sJ8SUTcOrrzjLJuS4LnmPUMlh+3VLGxSjcOsd/dVucQlrI3HTG/jJOkbboRLmyBYWKZkPZ43h+ssXpHzhz22eoS5u2eggqG1KMZi7gq0rmnY3XxX8T05xQWcYVsFDyaFDWLyjfq1capWKhHfhXQRqyR3E/J+9gVQxawbS2xSxFAgUh1izhGIDmAkWG8FvbYmEGPnk13O5YvZLN1AQPjpan4n/H91dDWoL/wuQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1725196610; bh=Z8cNQj8b6L4Udux4jBq1iPy4ArAAbTfU3R3n+67ioBf=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=COROWUS61Qk6j2R4Ad+MMVsqxpJzUXo8Vm7OWiXMCzWQRVZPAHt3hOcXDQSiuiPBLSgVW7rvceytbVfF/37vGjmeKC4Td5F9Xl4mdYPsgKPqyTM7LhzrSy78a+30LlS1b47YkmT2qh0sTfPchd5idD+5GPmUCk6k+ZIXJqb0NomCl8zbmVrs9GhCYJC3wAOZoHfIigEbPYvgKOWoPoabIIqAvB5tx0GisPdrUf1eGzJqPqmVOEMGc8/1bLbySYeGnBRfsCqmHfK6GC0BoqYQnRK1ifbRMvY3gBdkO8+y+bqNXwOmwUMik2cV5u/s4clblNyjPWucSUeQT+GvR+AsBA== X-YMail-OSG: NLi4JDAVM1nSZlWp3uvdMXSfu7btpMIXCVVkZ2A_E_ykfGXtVEKx4QUSU9sjc13 Gq59RzUdmGrW_PiV5gH9TRuVdgl8GLBVMmGOrnj.5aImtVdwFBnK13X9j4Co8KeKt4ddqju7iQZD wGYsh7pBy3lut7qeudgdZJRuT2dcwJGC_yO59BgfH4vlyptgUqaiCZiCWX_xI3vpC_gKQKmnNdFl 3T5ISxNAOpSlrgusuOMBEh73WIohdB0hncOIaIi58ZShqvILBseqfFiyeUL3nYSXHKVuf69MVtnt EQpl4prW4.s6TidA8uQfnUYZLOigetyknvmLbhH7XEeHOEmG7KZmC3gM7xmAp.0Qw97Rm7CTJLmp HgrbhUVTuvKmS.nVlSOlG4T_NCZQj7nXYqlkz.zZ2_QpYjMKYfqTpdMXxYyHJzcLQyD0Bp6EivIx dQOy8VX4d37.ueZbinE56glknWS7e2gjiThxryEf8bdFxkcIFAdYqsvSuBfXWdIZnKNvQEjVAaXF JhCGdBxENDcBeIa8y0WJjvBPFYTiJFgsj9jSioRPm3cyhRXax9Xn3KbkKpqfMU2AkEEQIQfCo1OH Zkp2BiqNsSF0ILfo2KKmXzi.11WMTaggcC8kKO7DpAEmvngx0gfQ0J3IyttrOv2y_eD3.Cm4bgZu GSWbBbGAFyX8cFYxai4efQEoNY.MC0WXzw3xd5nSEw_po5DNJHnHG6LHyVkHzyaBCDVC4ornt7B1 4M6htqkwNGGOmbNigDUQa166U8Qnt.0MslhhUL1OOK0ds.yb6.23unVXUZPttWm.7MgUCh4TqcJa Jx._E2bauuk_VkQL1LS.t20Aub2zHjRONAUNyDklh_SVuhpoXNXekb8hYsUAZCKu6.9AKUg1gim1 vexapLTULdbjcZDklcoPW_Z09cVxGM1TVJPfYjAVxnJDk9bctRy2omXMaXKibZJd9CYcTG73rcAL kM51Zxt_Sye82C72ijajGxOsyaVICCOtSq_JXq4_X1wJYn2hEdjumx5APZtRq4yM1SlNHFzQeEKa LmXuPqxSmXMGBN5u7_SwAXPcSbBeG2uuhhUaT2OY9pQ9EQRDb90zebBXZPWZ2.7TLGlWbxlotBoQ cL.zIvmyeKCmty4fLo5B9YYEU_Y8lbfDWlxYWe0Yqhi9Zm1Imx1f_MATq6SQdgCIF1FBw_S0XTsw fWqLCutApAo8k5Ef94Zs18pTj2tHuz_XkHntbYmVEvdACOxcaAK.OSFqTpdQiG21SvtHTvQgqFX8 aQWY5maS7xsyhY1FVN3O5as8HsL0dwQfizykk0J_mxrXxiNaJlXxPsPb.eJJzZS28xjT.bFS7Jks aOgIYjgkG97Hyqf4DEmefOsK5L7WOw3Q85j7gNGmWmtPoVR_0lFYlfsSNb6Dk0h9fJGC2HolGoJr lwb9jwd4d3oV7Jc79C32_VPOyaAJ9BiMAzUd3zLd984C7vTdHqdGZ8hZgzRkzE5P69OpeVXkTAd1 t34I67WGMPYyVdXcXp8HBEuVbfQX.GFIZcBXYinFlPp6Zvlf7luDeo0Ua2H_G3swB_dt8FttJ5TC vweO2MhZ7_PS6cy64CfE09YGon5iosSK4dhZ9bk.2tIGk6gT5mIleETMHaNwJ.E_5CaeyxztQ6bA yrY5pgVXn0V8MFkdUew3u06B4ykaqcdKTEOmdWe3G4OxJ4wkZvc_jS5LUWVUl9nVPAn5rDtqSOUF GP6O0B6HcHklC5VN09e16_7DqZRFftWKL2Z1b6rYPSYcd0aFli5LE3ErXR7VxmFPJnE3_GEgYVCt As4D5_kZgr3I9fsKDG.yMF6GZsTxI2jdRDJQEhiYk3w0rIVjWKVKd8A0FNXTGWTr8WqbklCYVOyE JUAkdjgRxR285xWsSieDRRdzgdHKpWhlDaLg7eEcjt6uFjBJzCsD0E90b9_HVSdT6eV3Z_vQxz_L qS_WrSVpl2ud7YOFdrLo9LpbmmLvSgKL17voJGys5uhZEeECdlMzVCBoR2nzG9cj7Bs3pAeW4Q8e z42Y4K8J55CRERMDhAk62GPxfxnW7tOSYYkNGq9NzOR.07zQS9e4G98.BwZBsXWSsabqsrpmIZJl iFZAkTGjFobk.kaveY3fXvznJ.5McnXnKq1L3SqdyaEzfkF5py3mtjXLrvc2TfqDD6YsKIOQnEhn lc0otrrPNGHGPRsa3Gqakqk57nm.sXO0zmV2n3MPLheC.QI0q7vbwx16IYg0TRA0N_gCUtIINjT6 PMRyHiXvJDcnaYIDTfAiWF6dr9Zd2fdEhd2SrcmRX2KU9SMFppF02DpCMC9puy4iHjhbj5VS7QFy s4A-- X-Sonic-MF: X-Sonic-ID: 7cf314f4-578b-42d2-8e01-7cc12ae957f7 Received: from sonic.gate.mail.ne1.yahoo.com by sonic310.consmr.mail.gq1.yahoo.com with HTTP; Sun, 1 Sep 2024 13:16:50 +0000 Received: by hermes--production-gq1-5d95dc458-c8wt4 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID dd6a910ea491e7aa1f4e23063d5157fc; Sun, 01 Sep 2024 13:16:46 +0000 (UTC) From: Mark Millard Content-Type: multipart/alternative; boundary="Apple-Mail=_BFF0A79E-5472-41A1-9761-46663CB5BC15" 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: ampere2 is building main-armv7-default again. It no loner hangs up where it used to Message-Id: <1C2E5086-4BC7-4B37-9DCD-DAAF814B89FF@yahoo.com> Date: Sun, 1 Sep 2024 06:16:36 -0700 To: FreeBSD ARM List X-Mailer: Apple Mail (2.3776.700.51) References: <1C2E5086-4BC7-4B37-9DCD-DAAF814B89FF.ref@yahoo.com> X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.94 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; 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)[multipart/alternative,text/plain]; NEURAL_SPAM_SHORT(0.06)[0.065]; RCVD_TLS_LAST(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TO_DN_ALL(0.00)[]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCPT_COUNT_ONE(0.00)[1]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; FREEMAIL_FROM(0.00)[yahoo.com]; FROM_HAS_DN(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; MID_RHS_MATCH_FROM(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.69.146:from]; APPLE_MAILER_COMMON(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.69.146:from] X-Rspamd-Queue-Id: 4WxXTx21lJz4HbX --Apple-Mail=_BFF0A79E-5472-41A1-9761-46663CB5BC15 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii = https://pkg-status.freebsd.org/ampere2/build.html?mastername=3Dmain-armv7-= default&build=3Dp15d22e1c70da_s871911a4a is where one can monitor ampere2's progress on building armv7 packages = for 15.0-CURRENT (a.k.a. main) for later distribution in detail. https://pkg-status.freebsd.org/builds?all=3D1&type=3Dpackage is where an = overall summary can be viewed in one of the rows. Thanks to Philip Paeps for updating the armv7 jails with a more modern = world version and such in order to pick up the earlier bug fix that = avoids the hangups that had been an issue since late Feb. (A recursive = lock context is now avoided.) =3D=3D=3D Mark Millard marklmi at yahoo.com --Apple-Mail=_BFF0A79E-5472-41A1-9761-46663CB5BC15 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii


is where one can = monitor ampere2's progress on building armv7 packages for 15.0-CURRENT = (a.k.a. main) for later distribution in = detail.

= https://pkg-status.freebsd.org/builds?all=3D1&type=3Dpackage = is where an overall summary can be viewed in one of the = rows.

Thanks to Philip Paeps for updating the = armv7 jails with a more modern world version and such in order to pick = up the earlier bug fix that avoids the hangups that had been an issue = since late Feb. (A recursive lock context is now = avoided.)


=3D=3D=3D
Mark = Millard
marklmi at = yahoo.com

= --Apple-Mail=_BFF0A79E-5472-41A1-9761-46663CB5BC15-- From nobody Sun Sep 1 21:02:03 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 4Wxkph68DNz5PS4h for ; Sun, 01 Sep 2024 21:02:04 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R11" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Wxkph1145z4D84 for ; Sun, 1 Sep 2024 21:02:04 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1725224524; a=rsa-sha256; cv=none; b=ABTIqe+OjPDqAe7YDTOlhh6MSVgwiIFckv8r4WlaqOptjseExnHtY4Ve4/BIbgDLYKQXS0 XDxqgqj3zsUJoKsPzjmKyq4NrLIoeTQpJGisY4Kgho3gb3VkWahkqQmi1UVOD+2rTqLTnL J+5fM6Z12EyOJ+ej9ILvGNuiTeP7oz1VPmMo2zKAgKxop0i6f0KgAoU45u8JsmyTo/r0Y6 BkwIioxGvGPFEdGzDY7lzAlvTEW0Fzfck8BHr7HHR6e0xB81nUneENeG7z9s82Cu2I+NsJ 8RQPKki9TIZzCxrOFHJ4I/KYtFGNARk/8RvgPu4N3AomQNp8JZ6AzGgUCR1epA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1725224524; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=gfoUzBH0/hO8kCj8mQ2mh67zZuQ91fAsUp7gxLLtEyQ=; b=DcV/XBNhhaoHpavKXlZEBP5Lpix8fk0ShJFGE7t4mqIpxj2dQ6a2jfE380F64UnBc02wjW GsZGbL6PBTl3zpqBD4+37MUSC0sYQOFhW7mcj9vHbPF1NbMYVz8KzAe3fjJzy1NmBQB6T0 KBT++pBWCiepUs7QNOKMxiDlFjojy4iuqUiAqjKSkJtKw4c070D6vp7sA/BqFvyYKikM/r FF76ci0vT2YGai2D9LZ1rkHpQyGhh9U2yT1N+XYm7OS2GtXcjXrGiHVs2SXLsw40eqpVm3 fWvOmhzT0zuKVFjVLu6qv3ZFmYaND5xdx3hcQDcciB4is0e4Wz1obvBEWCFpAQ== Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4Wxkph0b8PzkY1 for ; Sun, 1 Sep 2024 21:02:04 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 481L23tY087574 for ; Sun, 1 Sep 2024 21:02:03 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Received: (from bugzilla@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 481L23h2087573 for freebsd-arm@FreeBSD.org; Sun, 1 Sep 2024 21:02:03 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Message-Id: <202409012102.481L23h2087573@kenobi.freebsd.org> X-Authentication-Warning: kenobi.freebsd.org: bugzilla set sender to bugzilla-noreply@FreeBSD.org using -f From: bugzilla-noreply@FreeBSD.org To: freebsd-arm@FreeBSD.org Subject: Problem reports for freebsd-arm@FreeBSD.org that need special attention Date: Sun, 1 Sep 2024 21:02:03 +0000 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 Content-Type: multipart/alternative; boundary="17252245233.6ae7f.69655" Content-Transfer-Encoding: 7bit --17252245233.6ae7f.69655 Date: Sun, 1 Sep 2024 21:02:03 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" To view an individual PR, use: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=(Bug Id). The following is a listing of current problems submitted by FreeBSD users, which need special attention. These represent problem reports covering all versions including experimental development code and obsolete releases. Status | Bug Id | Description ------------+-----------+--------------------------------------------------- Open | 264574 | sdhci(4): Support ACPI attachment in BCM2835_sdhc 1 problems total for which you should take action. --17252245233.6ae7f.69655 Date: Sun, 1 Sep 2024 21:02:03 +0000 MIME-Version: 1.0 Content-Type: text/html; charset="UTF-8" 
The following is a listing of current problems submitted by FreeBSD users,
which need special attention. These represent problem reports covering
all versions including experimental development code and obsolete releases.

Status      |    Bug Id | Description
------------+-----------+---------------------------------------------------
Open        |    264574 | sdhci(4): Support ACPI attachment in BCM2835_sdhc

1 problems total for which you should take action.
--17252245233.6ae7f.69655--