From nobody Mon May 4 16:06:54 2026 X-Original-To: freebsd-current@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 4g8RPC40nhz6bm22 for ; Mon, 04 May 2026 16:07:27 +0000 (UTC) (envelope-from freebsd@walstatt-de.de) Received: from smtp052.goneo.de (smtp052.goneo.de [85.220.129.60]) (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 mx1.freebsd.org (Postfix) with ESMTPS id 4g8RPB03x1z3mB6 for ; Mon, 04 May 2026 16:07:25 +0000 (UTC) (envelope-from freebsd@walstatt-de.de) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=walstatt-de.de header.s=DKIM001 header.b=UPuPXRsY; dmarc=none; spf=pass (mx1.freebsd.org: domain of freebsd@walstatt-de.de designates 85.220.129.60 as permitted sender) smtp.mailfrom=freebsd@walstatt-de.de Received: from hub2.goneo.de (hub2.goneo.de [IPv6:2001:1640:5::8:53]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519) (No client certificate requested) by smtp5.goneo.de (Postfix) with ESMTPS id 98C1224033A for ; Mon, 04 May 2026 18:07:23 +0200 (CEST) Received: from hub2.goneo.de (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (No client certificate requested) by hub2.goneo.de (Postfix) with ESMTPS id 0DB44240371 for ; Mon, 4 May 2026 18:07:22 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=walstatt-de.de; s=DKIM001; t=1777910842; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type; bh=Gtkc7XAxhvTfhATvVhhC0T0EFO0JrsIs9jAHsc4O7SM=; b=UPuPXRsYnzTLKIC8gkN2IUe3FPqkaKRFp4khIE3NcA8zc9WbJ0pAzKrlAYSrX4nkMsIGPV nQ/YnpDmjhY/BJkX3qAYBXvzBpr4lxcoad4qa+G8vI/V9q77+Uj6laPBWbFb9QSCPpxhDe Ap4YX1OT48ARguSYW6u3T4jIcw4dRzLZwZ5PHL+PYWecjJhmkqTPeCqf2R/QMvOU5HaVtb vva8I0Gjmp8OTGQbMa0cH2XULR493qa8CBivSQ419vcw/qne2+2tVXLKYqH3x/wNlwVtWc kMl0QeaNOuJGWbFfDCSXItMaMqvY5LcWAUd9Cpi+USaf0DikqceckzqLMMt1vQ== Received: from thor.sb211.local (dynamic-2a02-3100-2f06-4102-1e48-9ee2-ebae-2faf.310.pool.telefonica.de [IPv6:2a02:3100:2f06:4102:1e48:9ee2:ebae:2faf]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (prime256v1) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by hub2.goneo.de (Postfix) with ESMTPSA id C80F9240024 for ; Mon, 4 May 2026 18:07:21 +0200 (CEST) Date: Mon, 4 May 2026 18:06:54 +0200 From: A FreeBSD User To: FreeBSD CURRENT Subject: /usr/share/mk/bsd.endian.mk:25: Unknown modifier ":aarch64 amd64 armv7 i386 powerpc64le riscv*" Message-ID: <20260504180626.0a3680dd@thor.sb211.local> X-Mailer: Claws Mail 4.4.0 (GTK 3.24.52; amd64-portbld-freebsd16.0) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Sig_/vBxwgkWCQoeFF6f9bdC8pir"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Rspamd-UID: 3d557b X-Rspamd-UID: 68c59e X-Spamd-Result: default: False [-5.70 / 15.00]; SIGNED_PGP(-2.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.999]; R_DKIM_ALLOW(-0.20)[walstatt-de.de:s=DKIM001]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; R_SPF_ALLOW(-0.20)[+ip4:85.220.129.0/25]; RCVD_IN_DNSWL_LOW(-0.10)[85.220.129.60:from]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:25394, ipnet:85.220.128.0/17, country:DE]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; RCPT_COUNT_ONE(0.00)[1]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; DMARC_NA(0.00)[walstatt-de.de]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TO_DN_ALL(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; DKIM_TRACE(0.00)[walstatt-de.de:+] X-Spamd-Bar: ----- X-Rspamd-Queue-Id: 4g8RPB03x1z3mB6 --Sig_/vBxwgkWCQoeFF6f9bdC8pir Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Hello, when building my world and kernel with crucial kernel modules for iGPU grap= hics as defined in /etc/src.conf: PORTS_MODULES+=3D graphics/drm-kmod PORTS_MODULES+=3D graphics/drm-66-kmod PORTS_MODULES+=3D graphics/gpu-firmware-amd-kmod ... I will receive an build error with the error shown below. Host is building most recent sources an host is at FreeBSD 16.0-CURRENT #13 main-n285656-5a6d9479ae22: Sun May 3 12:17:58 CEST 2026 amd64. [...] =3D> SHA256 Checksum OK for freebsd-drm-kmod-6.6.25-drm_v6.6.25_10_GH0.tar.= gz. =3D=3D=3D> Patching for drm-66-kmod-6.6.25.1600018_9 =3D=3D=3D> Applying FreeBSD patches for drm-66-kmod-6.6.25.1600018_9 from /usr/ports/graphics/drm-66-kmod/files =3D=3D=3D> Configuring for drm-66-km= od-6.6.25.1600018_9 =3D=3D=3D> Building for drm-66-kmod-6.6.25.1600018_9 /bin/mkdir -p /usr/obj/usr/src/amd64.amd64/sys/THOR/usr/ports/graphics/drm-66-kmod/work/d= rm-kmod-drm_v6.6.25_10/obj (cd /usr/obj/usr/src/amd64.amd64/sys/THOR/usr/ports/graphics/drm-66-kmod/work/d= rm-kmod-drm_v6.6.25_10 ; /usr/bin/env MAKEOBJDIRPREFIX=3D/usr/obj/usr/src/amd64.amd64/sys/THOR/usr/ports/graphics= /drm-66-kmod/work/drm-kmod-drm_v6.6.25_10/obj KMODDIR=3D"/boot/modules" SYSDIR=3D"/usr/src/sys" NO_XREF=3Dyes XDG_DATA_HOME=3D/usr/obj/usr/src/amd64.amd64/sys/THOR/usr/ports/graphics/dr= m-66-kmod/work XDG_CONFIG_HOME=3D/usr/obj/usr/src/amd64.amd64/sys/THOR/usr/ports/graphics/= drm-66-kmod/work XDG_CACHE_HOME=3D/usr/obj/usr/src/amd64.amd64/sys/THOR/usr/ports/graphics/d= rm-66-kmod/work/.cache HOME=3D/usr/obj/usr/src/amd64.amd64/sys/THOR/usr/ports/graphics/drm-66-kmo= d/work PATH=3D/usr/obj/usr/src/amd64.amd64/sys/THOR/usr/ports/graphics/drm-66-kmod= /work/.bin:/usr/obj/usr/src/amd64.amd64/tmp/bin:/usr/obj/usr/src/amd64.amd6= 4/tmp/usr/sbin:/usr/obj/usr/src/amd64.amd64/tmp/usr/bin:/usr/obj/usr/src/am= d64.amd64/tmp/legacy/usr/sbin:/usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/b= in:/usr/obj/usr/src/amd64.amd64/tmp/legacy/bin:/usr/obj/usr/src/amd64.amd64= /tmp/legacy/usr/libexec:/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/bin:/usr/l= ocal/sbin PKG_CONFIG_LIBDIR=3D/usr/obj/usr/src/amd64.amd64/sys/THOR/usr/ports/graphic= s/drm-66-kmod/work/.pkgconfig:/usr/local/libdata/pkgconfig:/usr/local/share= /pkgconfig:/usr/libdata/pkgconfig MK_DEBUG_FILES=3Dno MK_KERNEL_SYMBOLS=3Dno SHELL=3D/bin/sh NO_LINT=3DYES PR= EFIX=3D/usr/local LOCALBASE=3D/usr/local CC=3D"cc" CFLAGS=3D"-O2 -pipe -march=3Dnative -Wno-default-const-init-var-unsafe -fno-strict-aliasing " CPP=3D"cpp" CPPF= LAGS=3D"" LDFLAGS=3D" " LIBS=3D"" CXX=3D"c++" CXXFLAGS=3D"-O2 -pipe -march=3Dnative -Wno-default-c= onst-init-var-unsafe -fno-strict-aliasing -march=3Dnative " BSD_INSTALL_PROGRAM=3D"install -U = -s -m 555" BSD_INSTALL_LIB=3D"install -U -s -m 0644" BSD_INSTALL_SCRIPT=3D"install -= U -m 555" BSD_INSTALL_DATA=3D"install -U -m 0644" BSD_INSTALL_MAN=3D"install -U -m= 444" make obj) make[4]: /usr/share/mk/bsd.endian.mk:25: Unknown modifier ":aarch64 amd64 = armv7 i386 powerpc64le riscv*" while evaluating indirect modifiers "aarch64 amd64 a= rmv7 i386 powerpc64le riscv*" while evaluating variable "_ENDIAN_ARCH" with value "a= md64" in /usr/share/mk/bsd.endian.mk:25 in .for loop from /usr/share/mk/bsd.compiler= .mk:160 with cc =3D CC, X_ =3D ${_empty_var_} in /usr/share/mk/bsd.own.mk:297 in /usr/share/mk/= bsd.init.mk:21 in /usr/src/sys/conf/kern.opts.mk:21 in /usr/obj/usr/src/amd64.amd64/sys/THOR/usr/ports/graphics/drm-66-kmod/work/d= rm-kmod-drm_v6.6.25_10/Makefile:4 in make[4] in directory "/usr/obj/usr/src/amd64.amd64/sys/THOR/usr/ports/graphics/drm-66-kmod/work/= drm-kmod-drm_v6.6.25_10" make[4]: /usr/share/mk/bsd.endian.mk:53: Don't know the endianness of this = architecture in .for loop from /usr/share/mk/bsd.compiler.mk:160 with cc =3D CC, X_ =3D ${_= empty_var_} in /usr/share/mk/bsd.own.mk:297 in /usr/share/mk/bsd.init.mk:21 in /usr/src/sys/conf/kern.opts.mk:21 in /usr/obj/usr/src/amd64.amd64/sys/THOR/usr/ports/graphics/drm-66-kmod/work/d= rm-kmod-drm_v6.6.25_10/Makefile:4 in make[4] in directory "/usr/obj/usr/src/amd64.amd64/sys/THOR/usr/ports/graphics/drm-66-kmod/work/= drm-kmod-drm_v6.6.25_10" make[4]: stopped making "obj" in /usr/obj/usr/src/amd64.amd64/sys/THOR/usr/ports/graphics/drm-66-kmod/work/d= rm-kmod-drm_v6.6.25_10 *** Error code 1 --=20 A FreeBSD user --Sig_/vBxwgkWCQoeFF6f9bdC8pir Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iHUEARYKAB0WIQRQheDybVktG5eW/1Kxzvs8OqokrwUCafjEOQAKCRCxzvs8Oqok r1+3AQD3HVptZRGoM/mQitAywXtcd3YuaXEueifD9J7QaZaL7wD/ZltbL521RXdG SCG72Of5Pc7RnJm1cwG7RXvZb/VoBAA= =EM0X -----END PGP SIGNATURE----- --Sig_/vBxwgkWCQoeFF6f9bdC8pir-- From nobody Mon May 4 16:12:33 2026 X-Original-To: freebsd-current@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 4g8RWk45CRz6bn1m for ; Mon, 04 May 2026 16:13:06 +0000 (UTC) (envelope-from freebsd@walstatt-de.de) Received: from smtp052.goneo.de (smtp052.goneo.de [85.220.129.60]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4g8RWj3qlJz3p4q for ; Mon, 04 May 2026 16:13:05 +0000 (UTC) (envelope-from freebsd@walstatt-de.de) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=walstatt-de.de header.s=DKIM001 header.b=fm1dtQob; dmarc=none; spf=pass (mx1.freebsd.org: domain of freebsd@walstatt-de.de designates 85.220.129.60 as permitted sender) smtp.mailfrom=freebsd@walstatt-de.de Received: from hub1.goneo.de (hub1.goneo.de [IPv6:2001:1640:5::8:52]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519) (No client certificate requested) by smtp5.goneo.de (Postfix) with ESMTPS id 6248F24033A for ; Mon, 04 May 2026 18:13:03 +0200 (CEST) Received: from hub1.goneo.de (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (No client certificate requested) by hub1.goneo.de (Postfix) with ESMTPS id C98432402A5 for ; Mon, 4 May 2026 18:13:01 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=walstatt-de.de; s=DKIM001; t=1777911181; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=lRI9B6NODkfXscFFa0dy9IKX5l3i28jQVWIKC/pcMzg=; b=fm1dtQobX6eKD+jluWTesZJA8MAAWeYtj8iDhTtp9lzS/JSadz8j7SDqICZ4RYXgRXoFW2 MXwlBcu+HCjE6iMCwNtqhJ4HyfsBIPWOkyRdAX0rcatscxX/MMYbGmO8cKauzK819BeoKd OE5Nd23uQqSqKHj7y7mLJePJ8h/kXNQwujMSi5aisi/yvsDZfX3tYw+H/ZnYdCjgm/zkZd ocWXHyTmyPjo4PmBE6m3yOTdiQjWsPI0L6nYm63SBVKMGAzv3jf4w1kXJimbwQiZh16y96 UUHlEaNZPtn5RzrRqaucjwNJrm5Z49GP2TCJrGN6pO02S879I6s5GeaBunU2GQ== Received: from thor.sb211.local (dynamic-2a02-3100-2f06-4102-1e48-9ee2-ebae-2faf.310.pool.telefonica.de [IPv6:2a02:3100:2f06:4102:1e48:9ee2:ebae:2faf]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (prime256v1) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by hub1.goneo.de (Postfix) with ESMTPSA id 9680924027E for ; Mon, 4 May 2026 18:13:01 +0200 (CEST) Date: Mon, 4 May 2026 18:12:33 +0200 From: A FreeBSD User To: FreeBSD CURRENT Subject: Sorry, solved. Re: /usr/share/mk/bsd.endian.mk:25: Unknown modifier ":aarch64 amd64 armv7 i386 powerpc64le riscv*" Message-ID: <20260504181300.05ef8cd2@thor.sb211.local> In-Reply-To: <20260504180626.0a3680dd@thor.sb211.local> References: <20260504180626.0a3680dd@thor.sb211.local> X-Mailer: Claws Mail 4.4.0 (GTK 3.24.52; amd64-portbld-freebsd16.0) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Sig_//.YdZO1FnmlO=V_ZTAUpQsO"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Rspamd-UID: b7c5a5 X-Rspamd-UID: 426b07 X-Spamd-Result: default: False [-5.69 / 15.00]; SIGNED_PGP(-2.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.99)[-0.993]; R_SPF_ALLOW(-0.20)[+ip4:85.220.129.0/25]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; R_DKIM_ALLOW(-0.20)[walstatt-de.de:s=DKIM001]; RCVD_IN_DNSWL_LOW(-0.10)[85.220.129.60:from]; ASN(0.00)[asn:25394, ipnet:85.220.128.0/17, country:DE]; DMARC_NA(0.00)[walstatt-de.de]; RCVD_VIA_SMTP_AUTH(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCPT_COUNT_ONE(0.00)[1]; RCVD_TLS_ALL(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TO_DN_ALL(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[walstatt-de.de:+] X-Spamd-Bar: ----- X-Rspamd-Queue-Id: 4g8RWj3qlJz3p4q --Sig_//.YdZO1FnmlO=V_ZTAUpQsO Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Am Tage des Herren Mon, 4 May 2026 18:06:54 +0200 A FreeBSD User schrieb: Sorry for the noises. Workaround: install a full world/kernel without any s= ubmodule build and repeat. Then everything works smoothly as expected. oh > Hello, >=20 > when building my world and kernel with crucial kernel modules for iGPU gr= aphics as > defined in /etc/src.conf: >=20 > PORTS_MODULES+=3D graphics/drm-kmod > PORTS_MODULES+=3D graphics/drm-66-kmod > PORTS_MODULES+=3D graphics/gpu-firmware-amd-kmod > ... >=20 > I will receive an build error with the error shown below. >=20 > Host is building most recent sources an host is at FreeBSD 16.0-CURRENT #= 13 > main-n285656-5a6d9479ae22: Sun May 3 12:17:58 CEST 2026 amd64. >=20 > [...] > =3D> SHA256 Checksum OK for freebsd-drm-kmod-6.6.25-drm_v6.6.25_10_GH0.ta= r.gz. > =3D=3D=3D> Patching for drm-66-kmod-6.6.25.1600018_9 > =3D=3D=3D> Applying FreeBSD patches for drm-66-kmod-6.6.25.1600018_9 fro= m =20 > /usr/ports/graphics/drm-66-kmod/files =3D=3D=3D> Configuring for drm-66-= kmod-6.6.25.1600018_9 > =3D=3D=3D> Building for drm-66-kmod-6.6.25.1600018_9 =20 > /bin/mkdir -p > /usr/obj/usr/src/amd64.amd64/sys/THOR/usr/ports/graphics/drm-66-kmod/work= /drm-kmod-drm_v6.6.25_10/obj > (cd > /usr/obj/usr/src/amd64.amd64/sys/THOR/usr/ports/graphics/drm-66-kmod/work= /drm-kmod-drm_v6.6.25_10 > ; /usr/bin/env > MAKEOBJDIRPREFIX=3D/usr/obj/usr/src/amd64.amd64/sys/THOR/usr/ports/graphi= cs/drm-66-kmod/work/drm-kmod-drm_v6.6.25_10/obj > KMODDIR=3D"/boot/modules" SYSDIR=3D"/usr/src/sys" NO_XREF=3Dyes > XDG_DATA_HOME=3D/usr/obj/usr/src/amd64.amd64/sys/THOR/usr/ports/graphics/= drm-66-kmod/work > XDG_CONFIG_HOME=3D/usr/obj/usr/src/amd64.amd64/sys/THOR/usr/ports/graphic= s/drm-66-kmod/work > XDG_CACHE_HOME=3D/usr/obj/usr/src/amd64.amd64/sys/THOR/usr/ports/graphics= /drm-66-kmod/work/.cache > HOME=3D/usr/obj/usr/src/amd64.amd64/sys/THOR/usr/ports/graphics/drm-66-k= mod/work > PATH=3D/usr/obj/usr/src/amd64.amd64/sys/THOR/usr/ports/graphics/drm-66-km= od/work/.bin:/usr/obj/usr/src/amd64.amd64/tmp/bin:/usr/obj/usr/src/amd64.am= d64/tmp/usr/sbin:/usr/obj/usr/src/amd64.amd64/tmp/usr/bin:/usr/obj/usr/src/= amd64.amd64/tmp/legacy/usr/sbin:/usr/obj/usr/src/amd64.amd64/tmp/legacy/usr= /bin:/usr/obj/usr/src/amd64.amd64/tmp/legacy/bin:/usr/obj/usr/src/amd64.amd= 64/tmp/legacy/usr/libexec:/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/bin:/usr= /local/sbin > PKG_CONFIG_LIBDIR=3D/usr/obj/usr/src/amd64.amd64/sys/THOR/usr/ports/graph= ics/drm-66-kmod/work/.pkgconfig:/usr/local/libdata/pkgconfig:/usr/local/sha= re/pkgconfig:/usr/libdata/pkgconfig > MK_DEBUG_FILES=3Dno MK_KERNEL_SYMBOLS=3Dno SHELL=3D/bin/sh NO_LINT=3DYES = PREFIX=3D/usr/local > LOCALBASE=3D/usr/local CC=3D"cc" CFLAGS=3D"-O2 -pipe -march=3Dnative > -Wno-default-const-init-var-unsafe -fno-strict-aliasing " CPP=3D"cpp" CP= PFLAGS=3D"" LDFLAGS=3D" " > LIBS=3D"" CXX=3D"c++" CXXFLAGS=3D"-O2 -pipe -march=3Dnative -Wno-default= -const-init-var-unsafe > -fno-strict-aliasing -march=3Dnative " BSD_INSTALL_PROGRAM=3D"install -U= -s -m 555" > BSD_INSTALL_LIB=3D"install -U -s -m 0644" BSD_INSTALL_SCRIPT=3D"install= -U -m 555" > BSD_INSTALL_DATA=3D"install -U -m 0644" BSD_INSTALL_MAN=3D"install -U = -m 444" make obj) > make[4]: /usr/share/mk/bsd.endian.mk:25: Unknown modifier ":aarch64 amd6= 4 armv7 i386 > powerpc64le riscv*" while evaluating indirect modifiers "aarch64 amd64 = armv7 i386 > powerpc64le riscv*" while evaluating variable "_ENDIAN_ARCH" with value = "amd64" in > /usr/share/mk/bsd.endian.mk:25 in .for loop from /usr/share/mk/bsd.compil= er.mk:160 with cc =3D > CC, X_ =3D ${_empty_var_} in /usr/share/mk/bsd.own.mk:297 in /usr/share/m= k/bsd.init.mk:21 in > /usr/src/sys/conf/kern.opts.mk:21 in > /usr/obj/usr/src/amd64.amd64/sys/THOR/usr/ports/graphics/drm-66-kmod/work= /drm-kmod-drm_v6.6.25_10/Makefile:4 > in make[4] in directory > "/usr/obj/usr/src/amd64.amd64/sys/THOR/usr/ports/graphics/drm-66-kmod/wor= k/drm-kmod-drm_v6.6.25_10" > make[4]: /usr/share/mk/bsd.endian.mk:53: Don't know the endianness of thi= s architecture in > .for loop from /usr/share/mk/bsd.compiler.mk:160 with cc =3D CC, X_ =3D $= {_empty_var_} in > /usr/share/mk/bsd.own.mk:297 in /usr/share/mk/bsd.init.mk:21 in > /usr/src/sys/conf/kern.opts.mk:21 in > /usr/obj/usr/src/amd64.amd64/sys/THOR/usr/ports/graphics/drm-66-kmod/work= /drm-kmod-drm_v6.6.25_10/Makefile:4 > in make[4] in directory > "/usr/obj/usr/src/amd64.amd64/sys/THOR/usr/ports/graphics/drm-66-kmod/wor= k/drm-kmod-drm_v6.6.25_10" >=20 > make[4]: stopped making "obj" in > /usr/obj/usr/src/amd64.amd64/sys/THOR/usr/ports/graphics/drm-66-kmod/work= /drm-kmod-drm_v6.6.25_10 > *** Error code 1 >=20 >=20 --=20 A FreeBSD user --Sig_//.YdZO1FnmlO=V_ZTAUpQsO Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iHUEARYKAB0WIQRQheDybVktG5eW/1Kxzvs8OqokrwUCafjFjAAKCRCxzvs8Oqok r3LrAP9zMiF/sVq/tZi+gRcLvcNcZArNIW/yWBUfXHCeKhGhyAEAvMWTIiYeoHaM GkQqs8YuCuoSLFwn0xFG2Se6obR45Ag= =+hGL -----END PGP SIGNATURE----- --Sig_//.YdZO1FnmlO=V_ZTAUpQsO-- From nobody Tue May 5 01:25:31 2026 X-Original-To: freebsd-current@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 4g8gmy5KFPz6cvLD for ; Tue, 05 May 2026 01:25:22 +0000 (UTC) (envelope-from gperciva@tarsnap.com) Received: from mail.tarsnap.com (mail.tarsnap.com [54.86.246.204]) by mx1.freebsd.org (Postfix) with SMTP id 4g8gmx4Xyzz4DRZ for ; Tue, 05 May 2026 01:25:21 +0000 (UTC) (envelope-from gperciva@tarsnap.com) Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=pass (policy=none) header.from=tarsnap.com; spf=pass (mx1.freebsd.org: domain of gperciva@tarsnap.com designates 54.86.246.204 as permitted sender) smtp.mailfrom=gperciva@tarsnap.com Received: (qmail 10055 invoked from network); 5 May 2026 01:25:20 -0000 Received: from unknown (HELO localhost) (127.0.0.1) by mail.tarsnap.com with SMTP; 5 May 2026 01:25:20 -0000 Date: Mon, 4 May 2026 18:25:31 -0700 From: Graham Percival To: freebsd-current@freebsd.org, freebsd-git-weekly@tarsnap.com Cc: Colin Percival Subject: FreeBSD Git Weekly 2026-04-27 to 2026-05-03 Message-ID: List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spamd-Result: default: False [-2.61 / 15.00]; NEURAL_HAM_SHORT(-0.96)[-0.956]; NEURAL_HAM_MEDIUM(-0.74)[-0.738]; DMARC_POLICY_ALLOW(-0.50)[tarsnap.com,none]; NEURAL_HAM_LONG(-0.22)[-0.218]; R_SPF_ALLOW(-0.20)[+ip4:54.86.246.204/32]; RCVD_NO_TLS_LAST(0.10)[]; MIME_GOOD(-0.10)[text/plain]; RCVD_COUNT_ONE(0.00)[1]; MIME_TRACE(0.00)[0:+]; TO_DN_SOME(0.00)[]; FROM_HAS_DN(0.00)[]; ASN(0.00)[asn:14618, ipnet:54.86.0.0/16, country:US]; ARC_NA(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[54.86.246.204:from]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; MISSING_XM_UA(0.00)[]; R_DKIM_NA(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; RCPT_COUNT_THREE(0.00)[3] X-Spamd-Bar: -- X-Rspamd-Queue-Id: 4g8gmx4Xyzz4DRZ Hi all, I'm happy to announce FreeBSD git weekly for 2026-04-27 -- 2026-05-03: https://freebsd-git-weekly.tarsnap.net/2026-04-27.html It's a list of the 203 commits in that week, split into categories. Highlighted commits: - groups.7: New manual page of standard group names - RELNOTES: Add an entry for recent improvements to multicast routing - ports.7/FILES: Expand and refactor into 3 tables "Highlighted" commits are selected automatically if a commit modifies UPDATING, or if the commit message contains a "Relnotes:" line. If you think that another commit should be highlighted, let me know and I'm happy to make it so. To see all reports: https://freebsd-git-weekly.tarsnap.net/ This work is funded by cperciva@ and Tarsnap Backup Inc. Cheers, - Graham Percival From nobody Tue May 5 14:48:49 2026 X-Original-To: freebsd-current@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 4g91bX5c4Fz6cDqj for ; Tue, 05 May 2026 14:48:24 +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 "pelorus.zefox.org", Issuer "pelorus.zefox.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4g91bW1s7tz3b9t for ; Tue, 05 May 2026 14:48:23 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of fbsd@www.zefox.net has no SPF policy when checking 50.1.20.27) smtp.mailfrom=fbsd@www.zefox.net Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.18.1/8.18.1) with ESMTPS id 645EmnA7002431 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Tue, 5 May 2026 07:48:49 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.18.1/8.18.1/Submit) id 645EmnQ8002430 for freebsd-current@freebsd.org; Tue, 5 May 2026 07:48:49 -0700 (PDT) (envelope-from fbsd) Date: Tue, 5 May 2026 07:48:49 -0700 From: bob prohaska To: freebsd-current@freebsd.org Subject: ar: error: libclang.a: 'ParseDecl.o': section header table goes past EOF Message-ID: List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spamd-Result: default: False [0.98 / 15.00]; AUTH_NA(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_SPAM_MEDIUM(0.99)[0.989]; NEURAL_HAM_SHORT(-0.91)[-0.909]; MID_RHS_WWW(0.50)[]; WWW_DOT_DOMAIN(0.50)[]; MIME_GOOD(-0.10)[text/plain]; RCPT_COUNT_ONE(0.00)[1]; ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US]; MISSING_XM_UA(0.00)[]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; DMARC_NA(0.00)[zefox.net]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; R_DKIM_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; R_SPF_NA(0.00)[no SPF record] X-Spamd-Bar: / X-Rspamd-Queue-Id: 4g91bW1s7tz3b9t A Pi2B (armv7) is failing buildworld with: Building static clang library ar: error: libclang.a: 'ParseDecl.o': section header table goes past the end of the file: e_shoff = 0x131190 *** [libclang.a] Error code 1 .... make[4]: stopped making "all" in /usr/src/lib/clang/libclang .ERROR_TARGET='libclang.a' .ERROR_META_FILE='/usr/obj/usr/src/arm.armv7/tmp/obj-tools/lib/clang/libclang/li bclang.a.meta' .MAKE.LEVEL='4' ............ /usr/src was updated 5/4/26. Re-running git pull reports: Updating 8e8d87856241..9f2ad7c09709 and it looks as if only sbin and sys files have changed. I'll run a make cleandir and try again. If there are other things to try please let me know. Thanks for reading, bob prohaska From nobody Tue May 5 18:37:12 2026 X-Original-To: freebsd-current@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 4g96gh529Zz6c83M for ; Tue, 05 May 2026 18:37:20 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic304-24.consmr.mail.gq1.yahoo.com (sonic304-24.consmr.mail.gq1.yahoo.com [98.137.68.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 4g96gh1Qzpz3GxK for ; Tue, 05 May 2026 18:37:20 +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=1778006237; bh=qID8pVF7w/JbO0zDXPViOUjPnmSKHP7f/E/LNIR3hbY=; h=Date:Subject:To:References:From:In-Reply-To:From:Subject:Reply-To; b=ArsixAXZpEyV1XW6peKRvjjxqE1LzpshIvyDMe4DLiqQsYp6JA12g3PYCr1CBwc49i1z9xgvIaPnHXj+0SKmXePTZ4OBFy+35So29oLgGHsF8ppRBaUdADYidgHnqXtxbJeQOd+wrHnCbJJW7k6+L/9MAMuYf0LrNwj2Lc4y9vyLYm4tnBRi+ew9YY5MUiHgOrlKGNxrbijQFb5enOku5zLuZn0DIFR2PqqDykoMMD98IcaIl5bBkztaSIWAz5smRy3Tb3FmBwH/RVQfHWdQHjTZMG+qV4tVxbrBlSSHwASiENLbCbOkVh67W+QDKEUz71ltd/3sZjN/eEHHLO+Jxw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1778006237; bh=CHqk4MNZMB23Fo5P8ZWzh2R/vqCqLoxvQlOEiRQUETG=; h=X-Sonic-MF:Date:Subject:To:From:From:Subject; b=Hdjn1v7tubKF3fML3RDaeAlKtTlYyF/bl/OMNsN3DkeSm1eJbmKKOlbQ0L8CqER6J9rZzRSHLtb6mEloaAffqJ5w7sWPemNH0ip9EL4OxCPY+zlhbtWlfoS95waz0xa2V3YDAfQhmqsSKZOI8tInephqpIstSuV9m8WgNdsiypMyLwbwxURG6tTmYUX/3a+UKlGTcRYj8/4not8cSL83sshJhrH8I2i0t1gvi3MEaGFjT3dxlnjbyq+8qW0/cww20S1isr4SVG+v2YztNUwExKS9htcg+HHp0fu0laZFmtm4W5wDgGV0XlThfj8zNcxLBAsFyu/ndAyt8FkDPV01+g== X-YMail-OSG: qU7E9z8VM1kIyIbVxB9dYRL9e2rg1TpprymPa61CjYE11m4rdqI7Pslz0hEfalw j.2fnvYd0A6endz4t1qMgRE1qatsygNyxyZkBgFeLgLNstlOF9aNzLDggQdxHYDnVkxh9KBHJ_D7 Vs7kBqp01HsNpUynKp1AOU4Mrhn2rWtzQBA87ucTIOnmDi43mBfvcaXfkLsgczxm2hd8fkHAbT59 FBJe.79amPB54XMFd8XdMSKUunobdAFXsLjDqTMnbqgMhtu20_YJiT_mrGJW0XpaFvEU2HAUoUdj HynMMIlCe6u3e12OPHz4u.uTC663.6KtAQoZG8B3GJRtYk2.EYdWHizIzTkuhY9sgXVuXokKqwb. iG8Z3js4i8WRRoxznsOol5G8sC6CwquELwCuDOLtYP8_zZj9Hqhie9Ts.iIM9UFOXlDu3O2w9i3n mwyEpkDuDlcyWZJgY5sB.wyB_PvFcnqQDCMS9Oxs9NeprU93rWVXvuBvDvOsnGUGEd8mfeMG8fMN iExxpPE0aryO7r1iSFkq0Fi8AGBK.zuxSUz8VBJE2yL8mSFvpy3CKne5BZdp2_Xa5klrFDSyAIea cCkur5ayHugoInCopBBg7uQWO9caP.aO4z.culrRNFlvax.HA0KGPU6Y09S5zfi1gL8GdfGwk7fr z9Ne5NWOcPYFDta6Ir4MP4gjdc6IMw9vqZEc3Nl6PrhV_EUWXHsy.RFd_ARY.ljhQJBSmx832Tp. b6Gg7YWEobK.ziha3_NsSn4GxE1ZVxVqtXprb4Y1mCSgnNMsCUWcMiXzmRkhD2IRGVZDsZDGh0er 12YvIgck0t.wmxKB5CbdCs2EcKHcOxgfnBcspABl94zjsaWN6xjwkWqGD8uOmhQ0WtCWNew4qUD0 oBayZUzU5gVWehfEDO1SLziKrnCU.eTPLFcIilUqrQbbwogahkGb4bbsAcWyS3wk5.EKmuASqHsY QQDgr2hR9DpgtmbJ.h5vvVjGKlmmvSc_Kxiq5bfxZH_sM4_8umcy0QpNqvIMqSqtVs4ou99Tm5L7 VXjcmIC5f3M_oTzIRNy7OtV3Oedwu7u8XSdGattDaNcofb5bxFSe_WCioyWwGEGmMbwnXoPSxmOd N0Opq.8xywQjx.gXOEDAd2Ur.KQdF25XmfCXqK8bcgiStlemtXhcu1GFtq2XuT0PJWHwOkJrIIka P53Njmmq8XO1dcVeO_UO4uUXMs5k266HQBH8hTA.QmxaoTx4lkASOkYhuv_DSZYRtu1BZL3WgeJv CjSCJ89SYcdPXJiPE7TnjbFtheJ6zph4.8E8bHAfxeNXOI9HYAn8XGUbF4UXMgpWRAxG3UqRUKq6 P65eNOsX5OBKWfkeBtKZFsmtKSEvj0WMCRvqA56AlU7NFPl2d7ThaTUwrH6AzLfaFrOJX1AOHbqG l8uePeCtDjcH3kzLhKST5M4LVJZb.yxoCsPNlFDLhdhxaVkiWI9SxzZzY8jDCx9xarqKfIwex6xk VHLsZ8vticMKbqVowe3NVh9mcdg_BRzKdifIrfBqLgC4G5ixuQeyc0.Uau95Gm18V_1pIfcTjIrg _l8_8OfSgxmNSI22oRncakM9E0nzk_SMrs784sVFKOtiWgTWg8MctUuDpfRpmkWWFsyeCgya_zqq ysEinO0z92a12wdSNSbjJqrIOM6h0JC6zIyazmgKt.tSyJXZmgKVFFIDj3puM7R93Pa9AOnJlyrQ uv7cvAf28eJnD6mqLWFgaXQR8N7zXZEz_7QXeGZRsfEDtGqtAwfDfSs1zC4s7.tFZH7MZxDjNO81 MxDhokT7O2Tg3OeldtJx5fxU4uFaPqaUxT6Ba3WF.AAGvaafG5K_ncktu3MC6SKHIs_SA.VQNU5y C7UnFVHzf83UagJ0u1KZXDTSkQhVNNVZGAswSbOiK_gI3Tne244RJPpA5AvVFXtRHilRmbcEuBki yXbP5Dx630lNgCUxqol1syLP8.XW9mPdVe6q4wB9_R8yZ.OVnr97B9Tyyt.4Y43jJrUNDk9NpMi4 jAE68hX_dYnugbXjkdKIcR5Jwzu3dwtrAmvx5smwwssfi.mVDfgxlQGsv7.VQE5paTbTKj8bVttL Ah8UAsBy1avUqMNpm3qj0ODUJbcLqG7XmyIfLT3lT7g7efTxD1axqj92KOLxh0Eplb.Hq4pr1thG QNcFEZsB90FEhLNht.JRdUDPMA1gAarBm_m8K02_B4lyOWcdW2iaIuHvC2DyhnXuskwdYB7sibS4 2JVEZqENtlphMYNp.1jPb251fsAnlM3mb.8nY6lUgTaolylMyK5iYZoMPm7er9C2NJVLaB08OS8P Ufg9M4qvfh38Hw3ad5ukicwCN8N_QLGcNPgpiEpTr8P4NCeA- X-Sonic-MF: X-Sonic-ID: 8da63722-dc41-44b4-80eb-99fa80962287 Received: from sonic.gate.mail.ne1.yahoo.com by sonic304.consmr.mail.gq1.yahoo.com with HTTP; Tue, 5 May 2026 18:37:17 +0000 Received: by hermes--production-gq1-7bb7df5c46-m7ljh (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID b646e5c62b3058283bdfdbbe3634f880; Tue, 05 May 2026 18:37:13 +0000 (UTC) Message-ID: <2c2ab68d-83eb-4b6d-996d-10c2169a2165@yahoo.com> Date: Tue, 5 May 2026 11:37:12 -0700 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: ar: error: libclang.a: 'ParseDecl.o': section header table goes past EOF To: bob prohaska , freebsd-current@freebsd.org References: Content-Language: en-US From: Mark Millard In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailer: WebService/1.1.25559 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.yahoo 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: 4g96gh1Qzpz3GxK X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated On 5/5/26 07:48, bob prohaska wrote: > A Pi2B (armv7) is failing buildworld with: > > Building static clang library > ar: error: libclang.a: 'ParseDecl.o': section header table goes past the end of > the file: e_shoff = 0x131190 That error message can happen for the file content being corrupted. One form of corruption can be truncated because of running out of file system space. But there can be many others. Failed writes or later read-back problems are possibilities. Bad RAM content that was written out could be involved. Did you check the console output/log for any messages that might have been from the time frame(s) for the file generation or read-back? > *** [libclang.a] Error code 1 > .... > make[4]: stopped making "all" in /usr/src/lib/clang/libclang > .ERROR_TARGET='libclang.a' > .ERROR_META_FILE='/usr/obj/usr/src/arm.armv7/tmp/obj-tools/lib/clang/libclang/li > bclang.a.meta' > .MAKE.LEVEL='4' > ............ > > /usr/src was updated 5/4/26. > > Re-running git pull reports: > Updating 8e8d87856241..9f2ad7c09709 > and it looks as if only sbin and sys > files have changed. > > I'll run a make cleandir and try again. If there are > other things to try please let me know. There are a rather wide range of possibilities. If it turns out to not be readily reproducible, then the details may never be known. > > Thanks for reading, > > bob prohaska > > > -- === Mark Millard marklmi at yahoo.com From nobody Tue May 5 20:12:43 2026 X-Original-To: freebsd-current@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 4g98n943ncz6cJ5Q for ; Tue, 05 May 2026 20:12:13 +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 "pelorus.zefox.org", Issuer "pelorus.zefox.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4g98n90nQhz3bpV for ; Tue, 05 May 2026 20:12:12 +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.18.1/8.18.1) with ESMTPS id 645KCisd052006 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Tue, 5 May 2026 13:12:44 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.18.1/8.18.1/Submit) id 645KCiXC052005; Tue, 5 May 2026 13:12:44 -0700 (PDT) (envelope-from fbsd) Date: Tue, 5 May 2026 13:12:43 -0700 From: bob prohaska To: Mark Millard Cc: freebsd-current@freebsd.org Subject: Re: ar: error: libclang.a: 'ParseDecl.o': section header table goes past EOF Message-ID: References: <2c2ab68d-83eb-4b6d-996d-10c2169a2165@yahoo.com> List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2c2ab68d-83eb-4b6d-996d-10c2169a2165@yahoo.com> 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: 4g98n90nQhz3bpV X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated On Tue, May 05, 2026 at 11:37:12AM -0700, Mark Millard wrote: > On 5/5/26 07:48, bob prohaska wrote: > > A Pi2B (armv7) is failing buildworld with: > > > > Building static clang library > > ar: error: libclang.a: 'ParseDecl.o': section header table goes past the end of > > the file: e_shoff = 0x131190 > > That error message can happen for the file content being corrupted. One > form of corruption can be truncated because of running out of file > system space. But there can be many others. Failed writes or later > read-back problems are possibilities. Bad RAM content that was written > out could be involved. > > Did you check the console output/log for any messages that might have > been from the time frame(s) for the file generation or read-back? > > > *** [libclang.a] Error code 1 > > .... > > make[4]: stopped making "all" in /usr/src/lib/clang/libclang > > .ERROR_TARGET='libclang.a' > > .ERROR_META_FILE='/usr/obj/usr/src/arm.armv7/tmp/obj-tools/lib/clang/libclang/li > > bclang.a.meta' > > .MAKE.LEVEL='4' > > ............ > > > > /usr/src was updated 5/4/26. > > > > Re-running git pull reports: > > Updating 8e8d87856241..9f2ad7c09709 > > and it looks as if only sbin and sys > > files have changed. > > > > I'll run a make cleandir and try again. If there are > > other things to try please let me know. > > There are a rather wide range of possibilities. If it turns out to not > be readily reproducible, then the details may never be known. It seems reproducible to the extent that re-running buildworld provokes the same error after running make cleandir. Thanks for writing, bob prohaska From nobody Wed May 6 00:32:35 2026 X-Original-To: freebsd-current@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 4g9GY65fPbz6cxDn for ; Wed, 06 May 2026 00:32:10 +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 "pelorus.zefox.org", Issuer "pelorus.zefox.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4g9GXz6tqQz3Y0n for ; Wed, 06 May 2026 00:32:03 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of fbsd@www.zefox.net has no SPF policy when checking 50.1.20.27) smtp.mailfrom=fbsd@www.zefox.net Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.18.1/8.18.1) with ESMTPS id 6460WaQF055891 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Tue, 5 May 2026 17:32:36 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.18.1/8.18.1/Submit) id 6460Wa35055890; Tue, 5 May 2026 17:32:36 -0700 (PDT) (envelope-from fbsd) Date: Tue, 5 May 2026 17:32:35 -0700 From: bob prohaska To: bob prohaska Cc: freebsd-current@freebsd.org Subject: Re: ar: error: libclang.a: 'ParseDecl.o': section header table goes past EOF Message-ID: References: <2c2ab68d-83eb-4b6d-996d-10c2169a2165@yahoo.com> List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2c2ab68d-83eb-4b6d-996d-10c2169a2165@yahoo.com> X-Spamd-Result: default: False [0.70 / 15.00]; AUTH_NA(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.66)[-0.661]; MID_RHS_WWW(0.50)[]; WWW_DOT_DOMAIN(0.50)[]; NEURAL_SPAM_MEDIUM(0.46)[0.460]; MIME_GOOD(-0.10)[text/plain]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; MISSING_XM_UA(0.00)[]; RCVD_TLS_LAST(0.00)[]; TO_DN_SOME(0.00)[]; ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; RCPT_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; R_DKIM_NA(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; DMARC_NA(0.00)[zefox.net]; TO_MATCH_ENVRCPT_SOME(0.00)[]; R_SPF_NA(0.00)[no SPF record] X-Spamd-Bar: / X-Rspamd-Queue-Id: 4g9GXz6tqQz3Y0n On Tue, May 05, 2026 at 11:37:12AM -0700, Mark Millard wrote: > On 5/5/26 07:48, bob prohaska wrote: > > A Pi2B (armv7) is failing buildworld with: > > > > Building static clang library > > ar: error: libclang.a: 'ParseDecl.o': section header table goes past the end of > > the file: e_shoff = 0x131190 > > That error message can happen for the file content being corrupted. One > form of corruption can be truncated because of running out of file > system space. But there can be many others. Failed writes or later > read-back problems are possibilities. Bad RAM content that was written > out could be involved. > > Did you check the console output/log for any messages that might have > been from the time frame(s) for the file generation or read-back? > > > *** [libclang.a] Error code 1 > > .... > > make[4]: stopped making "all" in /usr/src/lib/clang/libclang > > .ERROR_TARGET='libclang.a' > > .ERROR_META_FILE='/usr/obj/usr/src/arm.armv7/tmp/obj-tools/lib/clang/libclang/li > > bclang.a.meta' > > .MAKE.LEVEL='4' > > ............ > > > > /usr/src was updated 5/4/26. > > > > Re-running git pull reports: > > Updating 8e8d87856241..9f2ad7c09709 > > and it looks as if only sbin and sys > > files have changed. > > > > I'll run a make cleandir and try again. If there are > > other things to try please let me know. > > There are a rather wide range of possibilities. If it turns out to not > be readily reproducible, then the details may never be known. It seems to be quite reproducible. After two runs of make cleandir and a git pull (which did find updates) the error repeats. Thanks for reading, suggestions welcome! bob prohaska From nobody Wed May 6 04:59:02 2026 X-Original-To: freebsd-current@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 4g9NTC4JQpz6dJk4 for ; Wed, 06 May 2026 04:59:11 +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 4g9NTC077Lz44T3 for ; Wed, 06 May 2026 04:59:10 +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=1778043546; bh=Lof8o0Esv5dVBwi6E8FRn8K3E8QfB470j53EWlk6D7k=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From:Subject:Reply-To; b=Al/vFjLiL9ebIHVFp6cyJ6ICP55MBuzJ9YP1rI9mhFbplmv8xj9O+NLySpNZXyKprsXJxVNU+ALU+XGA9uLYjcIX7PhkUCzJ2ceH3AhMImd6sJjmioddAhIkfPIrikrIAKx/tchM2Gxk+YycJKrHJb0eMbRLNj72pVxZ/sETvWUUXf+bHbkovfMUZ3Rd9wswjtIxGMRmXBPF4C9zix9jHil4JNjFjfDS0SJjreTiBMJcXrDp2lWKp1e1MZdhqpJoEQxaRW03XoLaLW662RvDrr1ubtXdfcD79sOn182EcWctaBnLifwaxCd/RJSsXrQjJxN4jO37HHqpwKKgALi0fA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1778043546; bh=zmBi9OCZnyGe2ZHs/XJjyuvwD+bqOm0KoiGOHrVjqTt=; h=X-Sonic-MF:Date:Subject:To:From:From:Subject; b=B6LO5e8CVEDSRWaHXqWeN7z4SwkB4KUQMjLBQ3HgPgvF64E6xoxbK8Uh4SnMjn7TIw0gSl51AOsLFaxzfzox2HY6uVX72aSIsxY5eXufCDYCwjJk5nzZNO5IPVTu+eSsI+TK4qetK37qT6Ifjx0IgYUD/pNThVfcZJoEiMpUtJBCUtZTe8z/jLULxUOxOwRI3MxR5zw/VR36AbLm4HyWqW0z/2tAMF78glsI94ie4qHWFI+Rr1nq7Qpr2QgqNpPyUmqFoCuoDOKanMTShulLSVxUzQb/GhP8KqDw2/b7V1Hgw9TAbEEDuX0i5WT7Ui7Uyg96UvLQpEHAFC5PA+cs4g== X-YMail-OSG: xmDYI2UVM1konKuLmphITCv4bIFT.hs0D6xwdr0NbSmaOhzD9rpJWjRTBaXaV.R KLXJMFr64cR7wgGL045p_aHxYHdWjLnL3PlEjHkkFHJ6MUPL_bkuTTAziFmSwwqz.0.UU6ICVCJ9 7kWdY.i.o61BZ3S26O1hsPsLMJUored7h8OdwMBQDCbfGXFUGaPdX_QUt_zGJ9_5KJ22jtXKziAY V5Ef5jNBsKZcgfDGHjmmOgnLqh7ZEcE1XZqB00M4z71NfZwvqJngZCWx94LEbZmII4tDR6AhPL.N 8UE0ovEWT8vVbii0RiSA5mkDtfr0eQEFJwwYpRBLz8TTo8_bzKG8Xw7qYpqJaW.bDnBSQDgTPYRM uXqumfinYu1nRln9Eh3TFS3J_2xtdTNDnbTMvTurSqmFPEFAwrIKkXJdTNf5ng3n8I.u98CBf.R0 MQTFlrHhrMoI0F8pUkyUSahQQJkTnqv04Dy6ivzGoo0z03WRTe63qm8kczNfEPvYvNHvuexFufdc hqigStJDMGmAjti1q6k3d6tPpvIFy.PpUInymcm32nfteU2g51llA5GewSLy3O_08flfdfK2LwYy 39kFBCphXcJuBitu1WJRKhI9C0qL2t2wdqp8lzN0T6gdtQu48_8aIgLph00HjqQl2xgyj3Xeulnp 7xenLe1F73njwqFNn011.5IqxNvMOD3Xjb3eiTx6S55aj_9W7g1hixH1lhXgouOo9FwHxssLumwT VW_XVfTiAsXBQdOTc7QYwY4B4y_GWwP.WPqqUwKZU4f5ZPKvT5lNVGuKwx9TgoB3finoJhs8iube FnWEkO.CIGDb414FUr1vZDgthj_z_Ufi4Um5TaQ.W3Cag0tpkfym4d6VNX4UVRG93u4d.Es3POQt Cscu6m.NdIXLRgSJ8Oeu7TzZ8gv6pGRQ6BeQMSPcqjrMi946m6C9b9pUEbrjMnGmvKDg084ETFrv uGWZCErUT401SmTA3LFiZdZM8Qa7MYpge4wxWjrLRUlVf.gbJkHEnenewtFSr7z38SkXGvK_2v4z dVdNOcn8HiW9tjbtI4w6zWvQ4S0IpdpYXa0V03lMzkfi2E3HX_Byhn96wHqSenEcTZne2D33O9TR 1h6iQyMAH9ZXm88VW0Zx9x2nu8TAWzXSWX.z95Qhyh0TOV9Nm6HNnJ8aR5D_y4dq_CbN_JI6T0ks y3lohufYIfbv_WQBG81HcuPguchTxXxX3zggg246gBaBy2LW8yBpCY.LJiTCvLLgbILIflk8GChs Rxf6EmNzCJtXj_l1ElCSQkTs1UyvLzUj930_XvhAjs1fgbm6pFeXqhqPqQxsqP4FhuBrp7ZxxdOf KaTKgQD76_2eYVSjWWByRDGV8KKSmg6JWpgWoHfm3NEwwe9SUS90F7dRC1FIR37NeEACknv8h_TK _D0V89iWyv5vbQEJVqAKUNCTn309Xk2HmjncTygoYeEYG_1PFWZ9YqGcCRGiWTkPHi.OhPN2sJt4 L6J4vtdSDCK0zGATrfW7cD4RayT6ZoxSuKbuXLvyMUqIsgftlwKcX9.6Xb_CvnhfoL0._vR10.wV igDvDTg2mLJrvWj3MBpG4UKrax95JVGWtfgdIFkRBXyP3uEcftUkiNn_vDYJCNebVs6uMTCEvQqU UCr2cYHnhPlBGvtFbA9yhImkPzTl3tDa5HvU3k7cPTgv0YcmMcblP70zb.Iq82uJygbdXNARH5JP ..uX3yTWH3oq6B0IAW0a2jbiiwGeEanrhenaEhwxv4H5zO1IJAlXF.cwsjF2W3rvrLUVtqcIN5dd lqe._KmnKsLwT5KH4n.8Yh7DiNYCADaBNcmFixS4vXnLEP346K7VTNkLZ4giJmoAB4JXYRqvtwXO 0b9YUZSM4akQ9ZlxQwzP2oT3hODOUj8zj3G552bmNnm8BN22drTmos0_iRoAbQUYMM7Hft8jvFSx RXaNdPHE7D988jsF_IzNbC2lOY4O7guprj.4XRnO94x8hs2rnMMws1pSE6KqtrVz2gcxJNAN6lY. txaeVZilOE4j39bV2CL2_oeS5MH7h4wT.KYHCgkl5uXelrbWMUWH5HbBsce6bk_7tqD6vu9GzZx0 txVejjsDuYne4VIIXhjzfQZt8pJaKCGc31OlhAHNPTASvC.oaK.tlnnqwkAF2jChIK8TumVzKzyu rmrgZsLNKB3093AH_ltO28TyAeI9grd9qsCp3O_vWg3LgVZwuyK5qh6NSeVJ7Iyss8PIctDhbBx0 pVoD6wn6lpWRUvu8z02kuDjxLEMcDGuwiUKBEl.1Xq6g847gk0St55N5LRr.q7.x_ptU82hBnq73 R7XVINEizE449SwPhPnVKdcAzywdZXs9zc75UuJ2HhWNBxDO57w-- X-Sonic-MF: X-Sonic-ID: 4aafd5a0-7de9-4eb3-93cc-d0a9aeb1a610 Received: from sonic.gate.mail.ne1.yahoo.com by sonic306.consmr.mail.gq1.yahoo.com with HTTP; Wed, 6 May 2026 04:59:06 +0000 Received: by hermes--production-gq1-7bb7df5c46-qhlmr (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 5533fdfbce37f149c8d0f5baf9d92498; Wed, 06 May 2026 04:59:02 +0000 (UTC) Message-ID: <4fab914f-ff17-4312-a098-975b6c103e05@yahoo.com> Date: Tue, 5 May 2026 21:59:02 -0700 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: ar: error: libclang.a: 'ParseDecl.o': section header table goes past EOF To: bob prohaska Cc: freebsd-current@freebsd.org References: <2c2ab68d-83eb-4b6d-996d-10c2169a2165@yahoo.com> Content-Language: en-US From: Mark Millard In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailer: WebService/1.1.25559 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.yahoo 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: 4g9NTC077Lz44T3 X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated On 5/5/26 17:32, bob prohaska wrote: > On Tue, May 05, 2026 at 11:37:12AM -0700, Mark Millard wrote: >> On 5/5/26 07:48, bob prohaska wrote: >>> A Pi2B (armv7) is failing buildworld with: >>> >>> Building static clang library >>> ar: error: libclang.a: 'ParseDecl.o': section header table goes past the end of >>> the file: e_shoff = 0x131190 How big is the ParseDecl.o file that gets this report? (Note the tmp/ in that path. Also the <> usage is in hopes of forming one long line and are not part of the file path.) >> >> That error message can happen for the file content being corrupted. One >> form of corruption can be truncated because of running out of file >> system space. But there can be many others. Failed writes or later >> read-back problems are possibilities. Bad RAM content that was written >> out could be involved. >> >> Did you check the console output/log for any messages that might have >> been from the time frame(s) for the file generation or read-back? >> >>> *** [libclang.a] Error code 1 >>> .... >>> make[4]: stopped making "all" in /usr/src/lib/clang/libclang >>> .ERROR_TARGET='libclang.a' >>> .ERROR_META_FILE='/usr/obj/usr/src/arm.armv7/tmp/obj-tools/lib/clang/libclang/li >>> bclang.a.meta' Can you publish the content of the file: These paths with arm.armv7/tmp/ involved are from the bootstrap build process, not the later normal build process. It is the attempt to create libclang.a that is reading ParseDecl.o and discovering/reporting the problem with the ParseDecl.o that had been generated earlier. >>> .MAKE.LEVEL='4' >>> ............ >>> >>> /usr/src was updated 5/4/26. >>> >>> Re-running git pull reports: >>> Updating 8e8d87856241..9f2ad7c09709 >>> and it looks as if only sbin and sys >>> files have changed. >>> >>> I'll run a make cleandir and try again. If there are >>> other things to try please let me know. >> >> There are a rather wide range of possibilities. If it turns out to not >> be readily reproducible, then the details may never be known. > > It seems to be quite reproducible. After two runs of make cleandir and > a git pull (which did find updates) the error repeats. > > Thanks for reading, suggestions welcome! > > bob prohaska > > > -- === Mark Millard marklmi at yahoo.com From nobody Wed May 6 14:50:30 2026 X-Original-To: freebsd-current@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 4g9db95TKWz6cjp5 for ; Wed, 06 May 2026 14:50:13 +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 "pelorus.zefox.org", Issuer "pelorus.zefox.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4g9db91cs2z3Mlq for ; Wed, 06 May 2026 14:50:13 +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.18.1/8.18.1) with ESMTPS id 646EoV9N006836 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Wed, 6 May 2026 07:50:31 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.18.1/8.18.1/Submit) id 646EoVJF006835; Wed, 6 May 2026 07:50:31 -0700 (PDT) (envelope-from fbsd) Date: Wed, 6 May 2026 07:50:30 -0700 From: bob prohaska To: Mark Millard Cc: freebsd-current@freebsd.org Subject: Re: ar: error: libclang.a: 'ParseDecl.o': section header table goes past EOF Message-ID: References: <2c2ab68d-83eb-4b6d-996d-10c2169a2165@yahoo.com> <4fab914f-ff17-4312-a098-975b6c103e05@yahoo.com> List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4fab914f-ff17-4312-a098-975b6c103e05@yahoo.com> 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: 4g9db91cs2z3Mlq X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated On Tue, May 05, 2026 at 09:59:02PM -0700, Mark Millard wrote: > On 5/5/26 17:32, bob prohaska wrote: > > On Tue, May 05, 2026 at 11:37:12AM -0700, Mark Millard wrote: > >> On 5/5/26 07:48, bob prohaska wrote: > >>> A Pi2B (armv7) is failing buildworld with: > >>> > >>> Building static clang library > >>> ar: error: libclang.a: 'ParseDecl.o': section header table goes past the end of > >>> the file: e_shoff = 0x131190 > > How big is the ParseDecl.o file that gets this report? > > # ls -l /usr/obj/usr/src/arm.armv7/tmp/obj-tools/lib/clang/libclang/Parse/ParseDecl.o -rw-r--r-- 1 root wheel 393216 May 3 19:15 /usr/obj/usr/src/arm.armv7/tmp/obj-tools/lib/clang/libclang/Parse/ParseDecl.o > > (Note the tmp/ in that path. Also the <> usage is in hopes of forming > one long line and are not part of the file path.) > Including the < and > in the pathname triggered a syntax error. Likely I misundersood the tip or I'm using a different shell. > > Can you publish the content of the file: > > The file has been placed at http://www.zefox.net/~fbsd/rpi2/20260506/ After placing it there using sftp, running file on it locally reported fbsd@www:~/public_html/rpi2/20260506 % file * ParseDecl.o: ELF 32-bit LSB relocatable, ARM, EABI5 version 1 (FreeBSD), missing section headers at 1249720 Perhaps unsurpisingly it can't be viewed in a browser. It does display neatly (but unintelligibly to me) using hexdump. Thanks for writing, please indicate any more experiments that come to mind. bob prohaska From nobody Wed May 6 15:11:56 2026 X-Original-To: freebsd-current@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 4g9f4Y49cfz6clg8 for ; Wed, 06 May 2026 15:12:13 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Received: from mail-ej1-x62a.google.com (mail-ej1-x62a.google.com [IPv6:2a00:1450:4864:20::62a]) (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 4g9f4X1LN1z3RV2 for ; Wed, 06 May 2026 15:12:12 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20251104 header.b="VeZzMJa/"; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of rick.macklem@gmail.com designates 2a00:1450:4864:20::62a as permitted sender) smtp.mailfrom=rick.macklem@gmail.com; arc=pass ("google.com:s=arc-20240605:i=1") Received: by mail-ej1-x62a.google.com with SMTP id a640c23a62f3a-bc356898256so516485266b.3 for ; Wed, 06 May 2026 08:12:12 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1778080330; cv=none; d=google.com; s=arc-20240605; b=dySEVCxqxw2XTXNx1yeum9i0LgnPSiWvc04Vy1Os3QOcvuxUu4ySm79iG9TAXIkpFK 4gsLW/NazMHkqcTdY0PLGRlKbLhYp7yUG+Vms+0CkIgorSt659ntJ0DTyu5k8BAHpcHK d4xwQS5nUnRITtbY1WzR5yFMvS/z6gwLTU3ruaKCsx4OWE9WBATPP+G3C000Skls9qqB CUBd5xGxdMg8wYIWjt4nsYLA5ELaD2cOHR4y1j5f4IpjQusVF2djZZn9qHcwmtwBX1sX bfIjyTL2vM3BVoTmxhrXjLwgPePS4lQBLEDBeTvzFlScet4wttfLoYY7JkrmOLwb+XW/ I9JA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=to:subject:message-id:date:from:mime-version:dkim-signature; bh=jgL746+N9L5RLMmTqOpZBz9gWz7ZVAxCtZJfUhIbuqo=; fh=/2t7RDVHVL+DuRZdfZ/FkHktsvSS6cz2dKFTm0B9krs=; b=fRPSgrioZ3KCFdWbJBZv2uB+4zV45VbFEPCPQUdUtJ+ruz38cvDxmNCNCXAZKuScIr xB+3avOylxZyyFGCYNcw9wUyVBGXLXUOvniK7hikijHmYHV10Yt4FcPP93WiAONlUNlu 0XxQgO8x+2y97d6ccOS2QRHkBkWt7GQuLSEiYCi+Td18MWAPwP0ZbEbkm6r2OllqSSt8 oRr47KKyFd2AuR7YiIv7ug4fUvYI2tqg3LxgnPA+O7nB5RzY5Pdl7cxgXOS8UICGEtua crVYAWcn/Sfg6ZChLCu6Mx+V9cd/mjGbiIOfzAFthyrsrsghk3sMJj1BQVM41ntjYLys YQ7A==; darn=freebsd.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1778080330; x=1778685130; darn=freebsd.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=jgL746+N9L5RLMmTqOpZBz9gWz7ZVAxCtZJfUhIbuqo=; b=VeZzMJa/B685jEEHJlsToBd+LoUlP3hatFfMFNB1OadZEP3ZaNIby9YyZbhSmmH1A1 jfzG7WO9btfYQfWGT0RLzG3KV1FzcJIaw+znWmTmxMU6mo0rfQnlT5B4B0tuQu2jly0R bO/NOeBSwvlXPkApbMCKJOmhgREZ3WOsoInM6nNwMk2hJWYWO4okSBzsGgc+tPWA6pn7 ucrcAKPzUI5sKfOuACYaSzA0jvrpgag/gX8AxyUdtm/IAlVZEaGvqQhv14y4hbHy/xwu 0iQ2tslTqk8+Rw/UE0oZd1dj8aZbWtpKNiyJkK/scYMr07tZNSSsedn9xKxdsorllkKP KlBA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1778080330; x=1778685130; h=to:subject:message-id:date:from:mime-version:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=jgL746+N9L5RLMmTqOpZBz9gWz7ZVAxCtZJfUhIbuqo=; b=sBhpibsDdcOTE3KcebM+x8Z5uMgN2Taj+ho8g3O4rAECyEowDkVx8l5QEql7/uh/IU bhzDU8xCnjah+UTev0tNM9KQE8nP1HMnXI77xdLYIP59WcnFIQ909C7ZRipkI9xj0HXC KchgldsixSMVQ9aqGRu9V/GTl/geOyMVg7mNjpzxSzLsEVqp8lDvE7Fax6lTYDMQwMDM CjJjadknuK00dTJOGE+EcBA5pSAHGDW1MHlRVZj5oxQGkc2HtLP2DsxhPg6zuYV2OUhN R3fi091qYPk2MGGIlHE2V0sDBS2Kb6wCSB+Tsk5XK2VKYp3pZGhZS+j4KJ7RiUhrSNie mVCw== X-Gm-Message-State: AOJu0YwbGQ78V9gQkNKlhRYWLcTopyzzFQmqEB6tt5WxNVn+TXrLJljA kMtaF55bdR2Kq8METoz4K31llMM4530XCwgbFNE46dmW+Bn4PE1UwaSka6po3Jl/gIHj72rZJPE YYoqs0PrC5gk3QmruhoTZN1VYvDFoLrXA X-Gm-Gg: AeBDiesarRmDsh3+bus5OywS9ZitQ6UNmelY2WJs86rSvDVYKytidCUyu3jlMhaBies opHbfrjhH7n3PaCgqPoSMaWttURvr3271xtWx8MQT4z0TgtB5PGb9QMr8jsiAC3jylq46Us1rPF PCXGa4lvJmwn97ve5bKoXVEsLN9ZTIyL+gJa7n8jYupi1EW+CVfaROaJlgu0vjuI8eUWl0pKjVf dDJ7pr18yCQgz0CxLpmvbGR+XMiZPnpZsrw0AiMb012sdXNueclQ9rBUWe6wIPUCS9naHOOtaBt LP048KG8Yajl1WeL3zl8P+m3OyOr1QsBp38HBgn7yRWFSyO5bg== X-Received: by 2002:a17:907:c0a:b0:baf:477:f11b with SMTP id a640c23a62f3a-bc56cd3bf11mr203190066b.20.1778080329614; Wed, 06 May 2026 08:12:09 -0700 (PDT) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 From: Rick Macklem Date: Wed, 6 May 2026 08:11:56 -0700 X-Gm-Features: AVHnY4L9SQsfT0Znk7rwyuMbrxqUL2HuOYVpt-ofsDy1p0IvKbpoO1AgfvZt7nA Message-ID: Subject: RFC: Can a new "don't cache" chflags(1) be added? To: FreeBSD CURRENT Content-Type: text/plain; charset="UTF-8" X-Spamd-Result: default: False [-3.99 / 15.00]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; ARC_ALLOW(-1.00)[google.com:s=arc-20240605:i=1]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.99)[-0.992]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4864::/56]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20251104]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; TO_DN_ALL(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; RCPT_COUNT_ONE(0.00)[1]; TAGGED_FROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_FROM(0.00)[gmail.com]; FROM_HAS_DN(0.00)[]; MISSING_XM_UA(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; MID_RHS_MATCH_FROMTLD(0.00)[]; RCVD_COUNT_ONE(0.00)[1]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::62a:from] X-Spamd-Bar: --- X-Rspamd-Queue-Id: 4g9f4X1LN1z3RV2 Hi, NFSv4.2 is getting a new "don't cache" attribute. It is meant to indicate to the NFS client that it should always handle the file as if it were open()'d with O_DIRECT. Does adding a new flag to chflags(1) called something like UF_DONTCACHE to support this new attribute seem reasonable? Thanks for any comments, rick From nobody Wed May 6 15:54:32 2026 X-Original-To: freebsd-current@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 4g9g1Z2MYxz6cpRS for ; Wed, 06 May 2026 15:54:42 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic303-24.consmr.mail.gq1.yahoo.com (sonic303-24.consmr.mail.gq1.yahoo.com [98.137.64.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 4g9g1Y2C4tz3WgH for ; Wed, 06 May 2026 15:54:41 +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=1778082878; bh=QNF3vgCdcocA6VMhPswSaSm15xSaEK0st0gGMe7cTmU=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From:Subject:Reply-To; b=LI4paM96X9ikr4y4rNCTAywV6tx4GcEYuikdcTEw3zDIduUnZasU7p1gr8Wh2muwcuTQ4522YORF6Ewer4aHGIYkKUSRG3L5SbFAW0WvGzTbEAUxHP4qLot4QQTIk6yJRY4fN9aS6P3hPZapvegC7bGzRQNfMBDx6erlkTmlqi0rmppnkpnouscM43UmCPtc6ZvKanS1CwrKvD9ip8XyDSsfXeP6aSnmLPN3ux1uDRInOKlfEwHVOCdRKdO8stwCwzqXmKAjkF+ywVB/iyG02PwxAsM4qB6g32IRjVYacrfZmSniyXWKfRlagsb09iJM+bnpCw9bKkaClRXl96cvUg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1778082878; bh=KYGviaaeYT24H9duRPtnRgZz7qlMkWctZfKDYiD5kQ3=; h=X-Sonic-MF:Date:Subject:To:From:From:Subject; b=YabW29kf9tjEGlCgDhNtCv5+iQXmAB6dkq69KMEMXNt5IuEMamOljfM1hoDrkhHjB9OWqo7BjGP/ahzpqYofZZ6Zx62Jtmcbv1pu0cqbYUkQ4A1zY6QLcoSlaLabNYUPbCb9PAZ8Pxr5BpEW9R1aY4ZzEMjEa6zhpbqvq4HP6xlF734fwVQ4bNRcJHr/12S+W5mnf9USnwFbKjkyKJUGdaJKZK/+TeQ1nPmFGAY579p4oO8vGOgZa7Q+08kKh7N9xG4iT3JApwuUmYQtTW1eBtbcy2/peLLdWqsdJR2X0mZJS/FwCEnOAcDey6L66+AtL3IsoE6TK+4HQ553Dygqtw== X-YMail-OSG: G08xKJcVM1mt0NC8wCMd3v3PKl7m6vYgS9iq9Bm92xwBfXeiGHGpJVTAwe4.Huf TbgYSSh4koJTXqnruMKOClu0CgMIKqRH_ThUnUQJKC.Q2EGOB9QZGY.WfIIQE9a89vzhxOqWYQrp .1BC6NISx0HhIFaV2e9uqT_DZnGyUUt6ODGJzb8AW1Llox72yKjhv25RyyUZy8e35RMVLdwm5fVM Vn9fnwNkYCujKwPvey9QvnxM8Q_YWuUfygkcButbd95khAM293FQj1o7Z9GGUXMxxA4dbaA4Pg7i nR81DGQNxifAD8NQIYdYIp2tLh00l8MwHpjqv.wwqFZkIlA1ndFtmO4OeojXlk6gAZRdmLsd8UQU .HSYi68HwKiQkbSxSxSHcmkbceAKZS2G1QMBsplUXrpCtGhI9aSCqRwzmVCjoVUtSCmmdZLbX5XS 2b8.yopLT1339prm1fHMbh402XJwBRb7hRi7oC.Y6N_illP0K29e.l00bOU1DrqwmFXXlRekFGKU wWyYdZwuHBm51MKHi3yxkbyJDhoB1eKp0tamX3IRcucXr7qeZjKF7PZraDwthq4rd_XJAGxV8Urd xKL7lLm.ZPSE73lNPRNMMb4WQvzL7mzq1j3P0JNlWx_wGGm4J.cWk.nxvgXBYHNpvju6EBJKSX._ PS8ZNQbQONaKKB_WRrsPCbXyVEi0yTybyZNeq6E4uvFztbBmhunkSguw1JnBd3bIMuvW2o7whj9N 6m3PV4VjPOsyAIlMr3HSUZhj5HF1fUZGsMLai.5RAYrScCuwcK463GFsF3FNUEH2j.zRabpPml7m CBdSrW68Shv5TwYE0I4MDL5Gg6pPk.FXGp3G7sUedGayIj2dyLiimZ8kVgIT6WnjDvS.ttdQrVsv inbvmNJbk31yDwq9FO.vHpeY0Duz_RCkTJf4OrCjBur7kAZlcQb84UiX_fR3L80r2gR86iQ4l.sX gNvrh4BUsw7vgeOGAuCePCxrZUwJ4Fstw9muCuZpeb4PXoHUp246Le3EQxJ4mdhYH_Z7y6.WPig7 q7G0DcgSdbrez_zXvl7_GPkxfRm3pInqWmpRp9lhE0YtaCGjvkE0_2.TKSNEaMyK7fk5yNebUicF i3Yzl9X72zL8lrI9G0VF7lFnQHcYSx5R_R0NcSdzC6bXN2jQQmOlrmyoY2vHfwX4W4gwTYdkKWGX tGIUzY0rEeofanRiLcLi4eaOeVcyj._euRnaorxPKGB4A1wJVX2f9jp3GzqCbKL2TWER2uKx3ws5 0Lcjy4LwOgDCYPce3wYSUyieo5Ndex8EsZnBfLh3qw6nXfsz1V3oXs9DizQXWlQrCpKDkWHWK6C1 IIGKjDiaYtnK42Qp5oRLGZWt.ddwMp.vQAp.kJUVlaDLYBGvHUDTmDE8wgP8loHuEIUXhLZBOK04 mP0VimDifRJpayVtTPzYzoEYhS9AlSDNJ38Iu.dpVOpI1JtA4mujPe.AmXG._oNtUQiM6srrApvk 0gUPnbRjiyKcm4.V.mm4tIYVgC9wToS58g7cLmDhyN2XO51qhoMk.x_CDBIM7mCPb81DdDEVoyPg h9fn5DLqACNeTzl5egbjIxm1BBjdTWuGc4VB5Ve_JBgh4qsjKg0petTY2RaTv3TaOK2lks4KgLwg gMXeCbGLpEQtv27j2pP84hb4icslt1Oo1f1Lwnvx9ZdIkQnmNb.gQO_ccneSGxG9PpJrdbRre4Ht aFhCjgah8yMl6cA2GejlV1L3qUoDP1ogNnDm6qgcgsYLHfH19aThCdnQ_vPraGU1yBpkxz78CrzX .l3cx_eVBDjrQXRMM2lnYmRCNggX2UIZCxR4S0TJ9tXfHRqSu8LH7sHafDt9C09DPDQhkk0jrEGj ckwcK52KByrW9n_yBhDpqlq7Ox_q0fxbN1ExyGY9OlqPR.dZ4nt5SNtmbFt0EhvpF1bZcu8fEwNk l2gVDUuL3gBDY3mYjoUMR7H31XgatSIpM3vFpZYpt438Dg8ZuTwwR6I5..G2LhA65dbA_FW2v7py Gm8cOgvUwNx.z0JAhVjJYWdr7vbfU.sqtSYxtPmOE8nMavPca0uKjmn7vB6um6sZ4FDI2dztFMQM QPCQEnq39onqZExGarc.pcxAAXDDpLZy0dqOQqQzlnk28UF_e8sVFey8GRfne8xgHqzK_nPjN62B pGflZ2RUpn._KVaghzZ0qKGkSuQIaNxE3zAptcNr64IJvjOfZZzCOIQgO4__JBZRFl0ar4cYI_mt diiSCAHAptz35LZYlhZ7.Fx.3tlCiLDulhUPkshPRgZ84PxSnCKQTfKS7E6dJ6XdHMMoU2RfCssu JkWDNVc.czYKGou4CNYOC.t_BVW6A64rXZ7TCmRYQh8qmdf4- X-Sonic-MF: X-Sonic-ID: 60299bb1-86fd-403d-bbbe-634a8b1978b9 Received: from sonic.gate.mail.ne1.yahoo.com by sonic303.consmr.mail.gq1.yahoo.com with HTTP; Wed, 6 May 2026 15:54:38 +0000 Received: by hermes--production-gq1-7bb7df5c46-nh65z (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 21d0393ae49662b873bbd31caa109003; Wed, 06 May 2026 15:54:33 +0000 (UTC) Message-ID: <413d71d1-6e18-4c7f-8844-d85c304d0504@yahoo.com> Date: Wed, 6 May 2026 08:54:32 -0700 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: ar: error: libclang.a: 'ParseDecl.o': section header table goes past EOF To: bob prohaska Cc: freebsd-current@freebsd.org References: <2c2ab68d-83eb-4b6d-996d-10c2169a2165@yahoo.com> <4fab914f-ff17-4312-a098-975b6c103e05@yahoo.com> Content-Language: en-US From: Mark Millard In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailer: WebService/1.1.25559 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.yahoo 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: 4g9g1Y2C4tz3WgH X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated On 5/6/26 07:50, bob prohaska wrote: > On Tue, May 05, 2026 at 09:59:02PM -0700, Mark Millard wrote: >> On 5/5/26 17:32, bob prohaska wrote: >>> On Tue, May 05, 2026 at 11:37:12AM -0700, Mark Millard wrote: >>>> On 5/5/26 07:48, bob prohaska wrote: >>>>> A Pi2B (armv7) is failing buildworld with: >>>>> >>>>> Building static clang library >>>>> ar: error: libclang.a: 'ParseDecl.o': section header table goes past the end of >>>>> the file: e_shoff = 0x131190 >> >> How big is the ParseDecl.o file that gets this report? >> >> > > # ls -l /usr/obj/usr/src/arm.armv7/tmp/obj-tools/lib/clang/libclang/Parse/ParseDecl.o > -rw-r--r-- 1 root wheel 393216 May 3 19:15 /usr/obj/usr/src/arm.armv7/tmp/obj-tools/lib/clang/libclang/Parse/ParseDecl.o That earlier 0x131190 was a offset in the file. 0x131190 == 1249680 . That is a lot bigger than 393216. > >> >> (Note the tmp/ in that path. Also the <> usage is in hopes of forming >> one long line and are not part of the file path.) >> > Including the < and > in the pathname triggered a syntax error. Likely I > misundersood the tip or I'm using a different shell. Only use the text inside the <>'s. The <>'s are an attempt to prevent the message I send from splitting the long text into more than one line in the process --even if I do not split it myself. Otherwise you might have to splice together the full path. Adding spaces just inside the <>'s would not work for the purpose, thus the lack of such spaces. > > >> >> Can you publish the content of the file: >> >> > > The file has been placed at > http://www.zefox.net/~fbsd/rpi2/20260506/ You published ParseDecl.o instead of publishing Parse_ParseDecl.o.meta . Parse_ParseDecl.o.meta is a text file produced by use of META_MODE . I expect it will include the text of the command that produced ParseDecl.o . Like earlier: omit the <> characters when extracting the path. > > After placing it there using sftp, running file on it locally reported > fbsd@www:~/public_html/rpi2/20260506 % file * > ParseDecl.o: ELF 32-bit LSB relocatable, ARM, EABI5 version 1 (FreeBSD), missing section headers at 1249720 So, apparently, the 1249680 offset was from 40 bytes into the file, leading to the 1249720 figure. > > Perhaps unsurpisingly it can't be viewed in a browser. > It does display neatly (but unintelligibly to me) using > hexdump. > > Thanks for writing, please indicate any more experiments > that come to mind. > > bob prohaska > > > > -- === Mark Millard marklmi at yahoo.com From nobody Wed May 6 16:07:26 2026 X-Original-To: freebsd-current@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 4g9gHh0HsGz6cqcB for ; Wed, 06 May 2026 16:06:56 +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 "pelorus.zefox.org", Issuer "pelorus.zefox.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4g9gHg0d1qz3Ynn for ; Wed, 06 May 2026 16:06:54 +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.18.1/8.18.1) with ESMTPS id 646G7R32049992 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Wed, 6 May 2026 09:07:27 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.18.1/8.18.1/Submit) id 646G7Ra2049991; Wed, 6 May 2026 09:07:27 -0700 (PDT) (envelope-from fbsd) Date: Wed, 6 May 2026 09:07:26 -0700 From: bob prohaska To: Mark Millard Cc: freebsd-current@freebsd.org Subject: Re: ar: error: libclang.a: 'ParseDecl.o': section header table goes past EOF Message-ID: References: <2c2ab68d-83eb-4b6d-996d-10c2169a2165@yahoo.com> <4fab914f-ff17-4312-a098-975b6c103e05@yahoo.com> <413d71d1-6e18-4c7f-8844-d85c304d0504@yahoo.com> List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <413d71d1-6e18-4c7f-8844-d85c304d0504@yahoo.com> 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: 4g9gHg0d1qz3Ynn X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated On Wed, May 06, 2026 at 08:54:32AM -0700, Mark Millard wrote: > On 5/6/26 07:50, bob prohaska wrote: > > On Tue, May 05, 2026 at 09:59:02PM -0700, Mark Millard wrote: > >> On 5/5/26 17:32, bob prohaska wrote: > >>> On Tue, May 05, 2026 at 11:37:12AM -0700, Mark Millard wrote: > >>>> On 5/5/26 07:48, bob prohaska wrote: > >>>>> A Pi2B (armv7) is failing buildworld with: > >>>>> > >>>>> Building static clang library > >>>>> ar: error: libclang.a: 'ParseDecl.o': section header table goes past the end of > >>>>> the file: e_shoff = 0x131190 > >> > >> How big is the ParseDecl.o file that gets this report? > >> > >> > > > > # ls -l /usr/obj/usr/src/arm.armv7/tmp/obj-tools/lib/clang/libclang/Parse/ParseDecl.o > > -rw-r--r-- 1 root wheel 393216 May 3 19:15 /usr/obj/usr/src/arm.armv7/tmp/obj-tools/lib/clang/libclang/Parse/ParseDecl.o > > That earlier 0x131190 was a offset in the file. 0x131190 == 1249680 . > That is a lot bigger than 393216. > > > > >> > >> (Note the tmp/ in that path. Also the <> usage is in hopes of forming > >> one long line and are not part of the file path.) > >> > > Including the < and > in the pathname triggered a syntax error. Likely I > > misundersood the tip or I'm using a different shell. > > Only use the text inside the <>'s. > > The <>'s are an attempt to prevent the message I send from splitting the > long text into more than one line in the process --even if I do not > split it myself. Otherwise you might have to splice together the full > path. Adding spaces just inside the <>'s would not work for the purpose, > thus the lack of such spaces. Ahhh, so user escapes, not shell escapes 8-) > > > > > >> > >> Can you publish the content of the file: > >> > >> > > > > The file has been placed at > > http://www.zefox.net/~fbsd/rpi2/20260506/ > > You published ParseDecl.o instead of publishing Parse_ParseDecl.o.meta . > > Parse_ParseDecl.o.meta is a text file produced by use of META_MODE . I > expect it will include the text of the command that produced > ParseDecl.o . > > Like earlier: omit the <> characters when extracting the path. > Apologies for the blunder! The correct file is now at: http://www.zefox.net/~fbsd/rpi2/20260506/Parse_ParseDecl.o.meta Thanks for writing, and your patience! bob prohaska From nobody Thu May 7 02:59:26 2026 X-Original-To: freebsd-current@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 4g9xmj6vCzz6dJMd for ; Thu, 07 May 2026 02:59:33 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic315-55.consmr.mail.gq1.yahoo.com (sonic315-55.consmr.mail.gq1.yahoo.com [98.137.65.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 4g9xmj1BRZz3fjX for ; Thu, 07 May 2026 02:59:33 +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=1778122769; bh=kkC2V1mPVZYkUEEwL7neU4L7NyWIiL3mva90aSaFdK4=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From:Subject:Reply-To; b=p9qTuFun1pl/XioneYn/IBN+UicwirfvkzpCxiUyd2aexq3Zo0IE+roct3JV+G9ubdC4DPMdSBgyYq4xqYW7PmRNK5YaqAqHFDPKM1CySx7tOTY510EHg0lu6+VSZlDXGOPlJy+1q6Pzczwjkq1QCemtbWTCHXwWQDklr9bKrxWJPVrLE6b+5dpLCZi+A2gsHvG3GElzTclSEdePfWbQgV5OJPhOxEB2vwmpUXeexhpQ3kM9foJ0xCW5dk2QLL53BIroJKnHsrVGEoMx/R62y0ha1wC7SS19Obn3YZwXAtqht+KkiN8RBx+bid5c0xWveylehIJJtbfFVuG6exsgnw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1778122769; bh=7LBeHC9xU1f5NvdUgjCOtaplFegcyGe73Hf2dGNPV7F=; h=X-Sonic-MF:Date:Subject:To:From:From:Subject; b=at3oT/FCcXETHXqe412d2Mqt1vbHe12UKOep7Ov+STzOEr34r5mKjH2MVhuTMCuCI6jSTo60q0azVvlOIVqM7NYzhPzs0siKoEoinWtEZRA9Ee15B6pVnrePqu6wPeFng6cBsM6L8MW09iA92WxetPD9qSyxDBJ875mZz0xq7L8O9o9PYs+z1X/FUBjIsaezRVd5ABax5+ui3+OTeUq2Q353Q+9h6V9q3R0CLjIcfXZWxRU2UmJ/nsp0SHnpAZ9rwuf8WvzNjVitghj5jUxqDaryqT3Blr1loeBEYG/9cFE4VNFb1XgBZiBWIItrN7XK5mYN3iy+s/nJ6l16MGpnmg== X-YMail-OSG: j7tl8EkVM1mo9k.rNdqm.S2bUWrHEc7BuG1g5I4ICnKKSuvTtSBGHvvEqYhXVGZ PGZRzjXbtX2qAdbuMuDiY8_IBeHsj50.lVqBU2qqHu0UD9xYUoBnggS1FQEDsd8pRsOF8iHMC06Q 1oDoidOLcba5rI3J0RCfbV5P1xK9Dq2bnxTOiXOaOVWUB2mORnZ6Fk09ltq94LXNh7ZjFC_5hoKV fSZY2BplpCGcCq5l.iEpPiNYJSDX_SV833YWdpajCwJjeFkuxwBrQ8splGMOevnUGQmJbYOMCDI0 ZnzK4rg9PRB93wBpi1.3REEUgQz80W.bf7HyUoxRwOx.576jPFmM15XtZtu84YNZjFk.dTlWdi.w 3X9P2tU4xAfjfGHlAjVdVAnVkk8h.lsfFrNr4fLUi.sZfvJ1bMvZ1Myw55iCd6o4mhszUo2hf1gN bXfp8ibkmWPooq5D_Z8f2bImjDx5O7LxeHKWbcd0cPKO2DfvYmngQoAKjL6Jk0YvWWuw65IiadZ1 AI9BIZCjeuuBwb8x4lt.1rGoMa_rwq_N9OyeqWE2T5Ox221mRPZZT0ObEf6h.ta6WPshqzmsTkjA pq4nwBdYSyo1L6fBbCyh9jqQPLLrs05vaQz_Mxy5ea4w2QknP_i8nZVz1Y3z4DfTfXydpKehc0KD 62kzLWcoh048S7dPMnm5TDMAMSPwOfh_iRNXpmNA5pgRJpHe9.wqX3Ou9oc5bM3zIBZivDCVxKD0 m0YcPUbX_x9m13Nrar4JXlvhZX1baFAxaXQeMFd_qVJR_MvmhrXaC29_.C8RWueutbW_MB5DIixX nI_ym7eZoJEXZ.WCtaztyVwutmlu3XNWD1A0zU_9TS_0sy1gEQROeC04StGdkO8tDc37l0S9ULRB L4o4pIX1h30FBWqmSy.4Kb_sS4gscZPurp4jv5EUpolpAinux1Ku6Dz4AdFsDc0NINpkzcd4F71b pKZtMHShuTUgxUzDsQRnILpw_6skxUmetjIDc86kiXJa8QuoveV6vCe581b3a5BpP2lHM.BexJ4b CoyNxaEbzhnnqs3jfTeJRLk.bc6xeLAoU7i28ipdtPtJcbDSTabDIedXXXTxyWKIlv2J2FIs9r7Q csmRpIEToCF4xvoJBCFwgKvt8kJYVFHCDJa4IyaHwVk601OgRKmrF5cIkBpPyg1gFlR5NZEe8of6 4z0Jg.RfvgpvluS_Pfg1Tq5xzfAmbNeO5myofK8szvIGcLDZ8loxem0ANegnn8lftQoKv51OJFZK H4Ibd12THe.fCK_oYHn5_w_U52iZ26u_0zGbmxQeo6TcdrTpYiJRfkiI1zM35vo3QJN7TbXV0QUa TPONrYwN7b_at6.6BKDFX4hO4TjusyrILUmB1uLLq5yd9fZfpmxnxpFS_HNCP79FIwTRG4dZEPPK fHj0g_y3z5HIX.OqC3PXEZTVmsJ2ai6X7pS1ur_NejqKKdF5QmmCEKTaWlbblktRpl.00NTxOiA2 u4K9aVxPaqTJLIsK_O6YbnR9nh96pr7uvX9OVgSsDwLrBmyF7l3Au2go7AV.MkH.4GXSZ3ErApzH ScYKXa9LaPcNfHWH0pfZV0b9fH05.D2DIfg9MTugE2Ui4HmMFEn5YDZmyxIU.wJdMz43GhXQWU0O .C5N89ARfQQrrlwik1G8TD7POHsgkc9FBmLg7SuPfpNKDgVP6.BW8icRuexSHZtK48Ns6MIojujq J4KLMfNGEAoUeDLm65u3WVXbTDbbHsYuX2ycuBmmT2sXEdm2yyimDDOSqiUyPk3g5EOuj.vcKHyk VscXp3PQB5hNTPzStEx1GuEMT0IJEfF3FxA3S5h5Pwh2Z933qwLlzO0djpE3AIais14hfw9JvO3W OXMw3pU6MKxe8vhMVfSp30r5KDwQnzACYIQR6A5mDJA2AoyheA_vvFufntUo37vEQurRaIfVlF9n BVTtMouN24X3Dm7PaddqRWv1fog18rQLMRseUTNppD1wA8NNgnCmPqGBwnaC.i0ou2XIjS6BRMDt xr.CIwUnrwY4OzTQ.vs3Ceb8L9nLoOM_8xKmnk3xmbGKPYInW1golDk7ek9D8bGr37sQhhiXsZLw v5kJ4X4pb8OABBhvNQhClMPQom4VblBckdM4X3vAylEr4ZsslYhbqVNpfGUm.yox.RWI.sbofeDP xZRNAoeGk73WB1X5rqRoN53ScoisvrJ.aCUUXZZqGnleG17izGOxdV52OiUVHGL4DbU3mf568lSz suZMeVLd3A0jnodX7qNRaoYS6yyok2vSGZdHyjzYmC_wB0BgfsRPZ9Zyjp2fTdkYq8BlT9A-- X-Sonic-MF: X-Sonic-ID: 3606c497-f940-4d6e-93b6-ffd7461ca1dd Received: from sonic.gate.mail.ne1.yahoo.com by sonic315.consmr.mail.gq1.yahoo.com with HTTP; Thu, 7 May 2026 02:59:29 +0000 Received: by hermes--production-gq1-7bb7df5c46-gm5fw (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 21888737708dffd0eb96dd893f6fea66; Thu, 07 May 2026 02:59:27 +0000 (UTC) Message-ID: <33436574-0b2b-4db8-a69f-85df46af12a6@yahoo.com> Date: Wed, 6 May 2026 19:59:26 -0700 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: ar: error: libclang.a: 'ParseDecl.o': section header table goes past EOF To: bob prohaska Cc: freebsd-current@freebsd.org References: <2c2ab68d-83eb-4b6d-996d-10c2169a2165@yahoo.com> <4fab914f-ff17-4312-a098-975b6c103e05@yahoo.com> <413d71d1-6e18-4c7f-8844-d85c304d0504@yahoo.com> Content-Language: en-US From: Mark Millard In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailer: WebService/1.1.25559 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.yahoo 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: 4g9xmj1BRZz3fjX X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated On 5/6/26 09:07, bob prohaska wrote: > On Wed, May 06, 2026 at 08:54:32AM -0700, Mark Millard wrote: >> On 5/6/26 07:50, bob prohaska wrote: >>> On Tue, May 05, 2026 at 09:59:02PM -0700, Mark Millard wrote: >>>> On 5/5/26 17:32, bob prohaska wrote: >>>>> On Tue, May 05, 2026 at 11:37:12AM -0700, Mark Millard wrote: >>>>>> On 5/5/26 07:48, bob prohaska wrote: >>>>>>> A Pi2B (armv7) is failing buildworld with: Which is true of the context: ) Is the old system one still using the llvm19 based clang related toolchain --so that the build needs to bootstrap the llvm21 based one? vs. ) Is the old system one already using the new llvm21 based clang-related toolchain --so that no bootstrap toolchain is needed (even if one is being built)? >>>>>>> >>>>>>> Building static clang library >>>>>>> ar: error: libclang.a: 'ParseDecl.o': section header table goes past the end of >>>>>>> the file: e_shoff = 0x131190 >>>> >>>> How big is the ParseDecl.o file that gets this report? >>>> >>>> >>> >>> # ls -l /usr/obj/usr/src/arm.armv7/tmp/obj-tools/lib/clang/libclang/Parse/ParseDecl.o >>> -rw-r--r-- 1 root wheel 393216 May 3 19:15 /usr/obj/usr/src/arm.armv7/tmp/obj-tools/lib/clang/libclang/Parse/ParseDecl.o >> >> That earlier 0x131190 was a offset in the file. 0x131190 == 1249680 . >> That is a lot bigger than 393216. >> >>> >>>> >>>> (Note the tmp/ in that path. Also the <> usage is in hopes of forming >>>> one long line and are not part of the file path.) >>>> >>> Including the < and > in the pathname triggered a syntax error. Likely I >>> misundersood the tip or I'm using a different shell. >> >> Only use the text inside the <>'s. >> >> The <>'s are an attempt to prevent the message I send from splitting the >> long text into more than one line in the process --even if I do not >> split it myself. Otherwise you might have to splice together the full >> path. Adding spaces just inside the <>'s would not work for the purpose, >> thus the lack of such spaces. > Ahhh, so user escapes, not shell escapes 8-) > >>> >>> >>>> >>>> Can you publish the content of the file: >>>> >>>> >>> >>> The file has been placed at >>> http://www.zefox.net/~fbsd/rpi2/20260506/ >> >> You published ParseDecl.o instead of publishing Parse_ParseDecl.o.meta . >> >> Parse_ParseDecl.o.meta is a text file produced by use of META_MODE . I >> expect it will include the text of the command that produced >> ParseDecl.o . >> >> Like earlier: omit the <> characters when extracting the path. >> > Apologies for the blunder! The correct file is now at: > http://www.zefox.net/~fbsd/rpi2/20260506/Parse_ParseDecl.o.meta > > Thanks for writing, and your patience! > > bob prohaska > > My guess is that, for an initially empty build tree in a armv7 context, a command sequence like: # cd /usr/src/ # env WITH_META_MODE= \ make -j3 \ WITHOUT_SYSTEM_COMPILER= \ WITHOUT_SYSTEM_LINKER= \ kernel-toolchain may be sufficient to have: generated instead of skipped, via avoiding use of the system compiler/linker, even if they are llvm21 based already. (In my context they are llvm21 based, as it is a preexisting upstream pkgbase distribution install from after llvm21 was updated that is doing the build.) I have such a llvm21-context build going in an armv7 chroot (in a context were -j8 is reasonable). Still, it is going to be some time before I know if the build repeated the problem vs. not. It may be that one has to start with an llvm19-based context to see the problem. I do not have such a llvm19 context available. -- === Mark Millard marklmi at yahoo.com From nobody Thu May 7 16:05:45 2026 X-Original-To: freebsd-current@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 4gBHD80wFyz6cmZK for ; Thu, 07 May 2026 16:06:00 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic314-19.consmr.mail.gq1.yahoo.com (sonic314-19.consmr.mail.gq1.yahoo.com [98.137.69.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 4gBHD72CKFz3XcZ for ; Thu, 07 May 2026 16:05:59 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=Hj78+LJP; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.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=1778169951; bh=9cXY9oo5LWIFFDUf4b5J3zmtY76cZl7J13tBTnIhI+E=; h=Date:Subject:From:To:Cc:References:In-Reply-To:From:Subject:Reply-To; b=Hj78+LJPgV2JzJ1UhpB27PszJOjiGVbMIb0CXv2abWVRQthNKx4LU1YSY/7nQZ8Yg8xCYEb1H2sHQIRCcZUXL+SkSxoOgNmvxR9VGK8ifJH7iq3DLUIvCZ5XZ2qW0NIP74RzCGK4uPmU8qye26bUfH7Zu3tErcolPWOD8U3q5bm29X03wCZX50forU6yyV460dcYU79GQomEIEWDQvjyLW7bvqVR9qGMe8TnQDtNg27VHbhPsDXf5mz4Hboo1Cp4PZSu0bYpA+2OFsNLtNdkr4KfjsGVCo62IlM7XSs3Zj21kozA/COvBP9duCGXnETBqj3qwV2577WXtJttxLAwbg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1778169951; bh=L1jcdGu7psUicfEvBSoPSs3eOqXSWe0ByPI8KcyNiyG=; h=X-Sonic-MF:Date:Subject:From:To:From:Subject; b=NRIUymX6gnjdYJxkvLFwl6GHn9jCHSuvihgbpMSruF2i8Jn7RGNHMLPSxk6XmWQC8ef7KpKVJgTnLay7htTJoOIYMET/Q7edCJRECxFs9bpUTkBhmACbnrmzbGxqcFLxiq1LskqtjslCjHjHQSnCgiaiTcpNvuWugf1UIwZ75yfwmohKIzDZV5EEb6dZVOITgvRbKzkuGg5VqxIOpKXT0V/Iob+eEHIS+4t1WPbFA8vNjELqsVxW/RuYeYQ+GDdTwDarZHVLZEbeQmGV67RIPS8xoosUxPktGAKkkIT7iNOKrXf1SHvwYY01CrlCO61m3BMfNbcvq1H/lV1057ybxQ== X-YMail-OSG: ONU9Gn0VM1m6P6nBClMWR2JaEgRXg0Jinh3umB6DjaRg6A2He40FsSd0Bd80lyJ bzfMztDhLDWNayMBG9OhoQP2jOpFL88XpFt77REHcSSGyTTpp_KKF30tiFxPx0TvxGrGNC8_qyYx pI3lSTUmNFdEn5n2m9UefzZ8Q.1i53O6.E0uUMXof33h85Ip9_q7RV6HqTjQDBlfKVOzUiFzdYwF lMGrYG4fBI8vcGYNApUfpe2F0oUY3HYsMH0ybRV_zGZwTOlsGreD3ok4bqZspDmjn32diuBf7W.n R4.0BxKQbXRalaaj.anosFzPPyVFJ_pleaIYPmBTQLWIJsqbIg7Hh.k.9ZQmpQTJbbYNjCCCxELF .lE6.XHsbGOkuCPAG9HGf8DY6ebV1egFQgVe0a5gfSNXXCqgb.gXgw.heTaoDhl9rVb2zFxx5ZLQ 91VkKCZKYCBZpa4VshScK5G.8tXQKKAXI8N8wz53q6bGtwE28M0jvHEzDuTqThQYZXxX4Whh39WB 7qFAK2vtnYZrjTOzZZWIsyV76anQ_l35YiWnwTQkBqVPw1x3cwHhTWCjZ5l8_f4J6JPT5VG0V_ql stTjsDl4h8XkYi2s8L._zq6n5W.0WllLBkIhTQ4VgZrA2aHIUupmxqC8cpOBrJ8PT0J6THGcBzaG z_6Thu2V7gXzAcgO25c9HyFu1L.VndfPZNRn06HvOQSV664j6xRLrIlAALLwVV.w1SdaIF.pAfPT lgnn2YI0ky_ihpRbRGh0UKRwj9.DYnhhwGhFjaDXVtMr3oJYeFqpIETDM2iW1megzWJztOakLwd2 cTLyEyXvbDymmWfjUZtgMgaD458S0tII9vRo42TYI9Vs5Z9RO4OzB6JJA3qw6bQZ5n3ghKhI_OSn piysrd6YFERI00Xid_UtHsHQS.gtBWyBb5zrzwkkz2zrWroucOZRuNhcvDYLZgJ2w8KK3IaU2tgl w5kuwUnlNPdKDoLfWlpvTLgrRCWE7IaHzRGmGUAKWKjJMiWMotUCfokhkm2id4j4A9l3JarhEaW6 zT8nxTPB748249Imc_BZPuN42gNLuRS.Fao7.kOooATc0ipVmbUEf0.YESQoZzz.8TBoQDRDRZzM kx3Iqm0V.jwQ.9E2bq6KaMejj.D54nTVs9WScV0VDgTaVVIdXBeDTO44PVnjsnirANcl0x3U7Lo0 iP6YhRkbWOIUVbdKvAgI3hyP_rJFFNP3VjGsgs64un0VAzh1WiEbuAo.eoEHAgOCUj_Ya0pw84X0 B1l6XRUa15fO.DqpsYFCDnGKkUy4K8oSFnNQv6n2v17WK.1S8htM5d.5OZKu9xEG2bptoMphWQix AiOMUj3Cm9lGQGBOkE2HibAOytJ0PRSPShSLf2JdBFCjU8hUdCRNb_u5u1aYx9Hs.fJ26TdZJNM9 6anpOzr6xumajyOB5vmdZsQ.UKGLH.JhszDilYv8vN4P8SW1wS.xb.5.tiDfMMLa6VLxx5zwsSUV w0HspVjSLH36mI5hLPXVjckOZqL4mlFn1NgT5bJz8jqTS9rnNpKf22S_7UL6LktVdX5cFL5NSIjO KUbdN3u7Wg.bMg6IwlwLXzTl8nlPRDFRMitJBajeXNPDkqdQT88gT04QUUvJR.8xS61nNo2Ebb3W KF4E7x1em7a7siB823c4cFru6v8_VhdXIG3ClI3GWab16hQvm.ew5Ayvu3EnGB1C5iHcQyCn6wIU ImvXayQz9w4d2YWAcee4Ju22iGHxTnwAXgHpLy4m2YPVpKLsTNzdzoAirhH0tJMBgtcrqaMjRJpE AfPQ7lmtSxXLcaxiyUfL7UQqdl_LX4VPwVQYgSj1hWarLvgfCHKupO7VgfLA_qX03o5L56KKeMq9 bQnNre_ZuvoMYIRsWC8vRNGDMlEUmxrBK_.lnlzB_gC7hEtNUkJxQOElidV4vBxzfXmfUlLkagba 5ZhBUhVTCYqv3SHBdJRWO8WHLTSP90jEA4gvbNSeZuaq7OlEVAImVEyNRqLhqsjiuuPVw18_xoe2 2kQcvk60iS7A2dqI.Vxhvg1AvHyo52aCyZ8cc0C79CVC9HQW8d5ouB0hijN_w7UzSF1cUMka97C_ KwuXMc6yf8E3G_2d2.yw6IYhKcn8LaBjlrOEPTbtlnb8jERD04D8cY7BQks_BtKkUjf9gIUPtrCW 3Kbb3jeAMAQLnKsThP69KWTd5jMqxxrgM9u5UU96XTQ1HxJa5kc8rol2N.0tkm99sEuCyP_462WH NE_SnV5TvgcLKDoIzmDpCWy82m7OfS1OwQ0oumJlwlGf.Pv6QI5r7fE8OZCNXWWlx6S4WmJPtJR. 9VEwcB_tt0pQXZ_x1iL1XpTJm.pAMuBod3IHG.s9YAGYoofg- X-Sonic-MF: X-Sonic-ID: 76bda665-2a28-46af-bea1-2b8839050e4b Received: from sonic.gate.mail.ne1.yahoo.com by sonic314.consmr.mail.gq1.yahoo.com with HTTP; Thu, 7 May 2026 16:05:51 +0000 Received: by hermes--production-gq1-7bb7df5c46-m4r75 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 06b4cb469145a2d3649a532f34d37969; Thu, 07 May 2026 16:05:47 +0000 (UTC) Message-ID: <7e29fc11-9fcc-4a71-97bb-b709862e35e1@yahoo.com> Date: Thu, 7 May 2026 09:05:45 -0700 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: ar: error: libclang.a: 'ParseDecl.o': section header table goes past EOF [Looks to be: armv7 llvm19 fails to build bootstrap llvm21] From: Mark Millard To: bob prohaska Cc: freebsd-current@freebsd.org, dim@FreeBSD.org References: <2c2ab68d-83eb-4b6d-996d-10c2169a2165@yahoo.com> <4fab914f-ff17-4312-a098-975b6c103e05@yahoo.com> <413d71d1-6e18-4c7f-8844-d85c304d0504@yahoo.com> <33436574-0b2b-4db8-a69f-85df46af12a6@yahoo.com> Content-Language: en-US In-Reply-To: <33436574-0b2b-4db8-a69f-85df46af12a6@yahoo.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailer: WebService/1.1.25559 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.yahoo X-Spamd-Result: default: False [-3.95 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-0.997]; NEURAL_HAM_SHORT(-0.96)[-0.955]; 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]; RCVD_TLS_LAST(0.00)[]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; TO_DN_SOME(0.00)[]; MIME_TRACE(0.00)[0:+]; 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.82:from]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.69.82:from]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim] X-Spamd-Bar: --- X-Rspamd-Queue-Id: 4gBHD72CKFz3XcZ On 5/6/26 19:59, Mark Millard wrote: > On 5/6/26 09:07, bob prohaska wrote: >> On Wed, May 06, 2026 at 08:54:32AM -0700, Mark Millard wrote: >>> On 5/6/26 07:50, bob prohaska wrote: >>>> On Tue, May 05, 2026 at 09:59:02PM -0700, Mark Millard wrote: >>>>> On 5/5/26 17:32, bob prohaska wrote: >>>>>> On Tue, May 05, 2026 at 11:37:12AM -0700, Mark Millard wrote: >>>>>>> On 5/5/26 07:48, bob prohaska wrote: >>>>>>>> A Pi2B (armv7) is failing buildworld with: > > Which is true of the context: > > ) Is the old system one still using the llvm19 based clang related > toolchain --so that the build needs to bootstrap the llvm21 based > one? > vs. > ) Is the old system one already using the new llvm21 based clang-related > toolchain --so that no bootstrap toolchain is needed (even if one is > being built)? > >>>>>>>> >>>>>>>> Building static clang library >>>>>>>> ar: error: libclang.a: 'ParseDecl.o': section header table goes past the end of >>>>>>>> the file: e_shoff = 0x131190 >>>>> >>>>> How big is the ParseDecl.o file that gets this report? >>>>> >>>>> >>>> >>>> # ls -l /usr/obj/usr/src/arm.armv7/tmp/obj-tools/lib/clang/libclang/Parse/ParseDecl.o >>>> -rw-r--r-- 1 root wheel 393216 May 3 19:15 /usr/obj/usr/src/arm.armv7/tmp/obj-tools/lib/clang/libclang/Parse/ParseDecl.o >>> >>> That earlier 0x131190 was a offset in the file. 0x131190 == 1249680 . >>> That is a lot bigger than 393216. >>> >>>> >>>>> >>>>> (Note the tmp/ in that path. Also the <> usage is in hopes of forming >>>>> one long line and are not part of the file path.) >>>>> >>>> Including the < and > in the pathname triggered a syntax error. Likely I >>>> misundersood the tip or I'm using a different shell. >>> >>> Only use the text inside the <>'s. >>> >>> The <>'s are an attempt to prevent the message I send from splitting the >>> long text into more than one line in the process --even if I do not >>> split it myself. Otherwise you might have to splice together the full >>> path. Adding spaces just inside the <>'s would not work for the purpose, >>> thus the lack of such spaces. >> Ahhh, so user escapes, not shell escapes 8-) >> >>>> >>>> >>>>> >>>>> Can you publish the content of the file: >>>>> >>>>> >>>> >>>> The file has been placed at >>>> http://www.zefox.net/~fbsd/rpi2/20260506/ >>> >>> You published ParseDecl.o instead of publishing Parse_ParseDecl.o.meta . >>> >>> Parse_ParseDecl.o.meta is a text file produced by use of META_MODE . I >>> expect it will include the text of the command that produced >>> ParseDecl.o . >>> >>> Like earlier: omit the <> characters when extracting the path. >>> >> Apologies for the blunder! The correct file is now at: >> http://www.zefox.net/~fbsd/rpi2/20260506/Parse_ParseDecl.o.meta >> >> Thanks for writing, and your patience! >> >> bob prohaska >> >> > > My guess is that, for an initially empty build tree in a armv7 context, > a command sequence like: > > # cd /usr/src/ > # env WITH_META_MODE= \ > make -j3 \ > WITHOUT_SYSTEM_COMPILER= \ > WITHOUT_SYSTEM_LINKER= \ > kernel-toolchain > > may be sufficient to have: > > > > generated instead of skipped, via avoiding use of the system > compiler/linker, even if they are llvm21 based already. (In my > context they are llvm21 based, as it is a preexisting upstream pkgbase > distribution install from after llvm21 was updated that is doing the build.) > > I have such a llvm21-context build going in an armv7 chroot (in a > context were -j8 is reasonable). Still, it is going to be some time > before I know if the build repeated the problem vs. not. > > It may be that one has to start with an llvm19-based context to see the > problem. I do not have such a llvm19 context available. > > Bob sent Email that was not sent to the list that reported his context upgrade context is starting with an environment that has: QUOTE Clang -v reports FreeBSD clang version 19.1.7 (https://github.com/llvm/llvm-project.git llvmorg-19.1.7-0-gcd708029e0b2) Target: armv7-unknown-freebsd16.0-gnueabihf Thread model: posix InstalledDir: /usr/bin Build config: +assertions END QUOTE My test case was llvm21 based, no bootsrap needed --but when Iforced a boostrap, llvm21 boostrapped itself just fine. Thus, it looks like the armv7 llvm19 context has a problem that prevents source code building the llvm21 bootstrap context correctly. At this time I do not have an armv7 llvm19 based context to independently test. -- === Mark Millard marklmi at yahoo.com From nobody Thu May 7 19:24:41 2026 X-Original-To: freebsd-current@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 4gBMdb6jmFz6d3Vl for ; Thu, 07 May 2026 19:24:51 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic311-24.consmr.mail.gq1.yahoo.com (sonic311-24.consmr.mail.gq1.yahoo.com [98.137.65.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 4gBMdZ2ffCz47Wm for ; Thu, 07 May 2026 19:24:50 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=KrAV2YXJ; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.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=1778181887; bh=jfi5V6E9m1trtzlbeAWQznnlhJR4CBzX4aAy9vaZ6bo=; h=Date:Subject:From:To:Cc:References:In-Reply-To:From:Subject:Reply-To; b=KrAV2YXJettE0jOlCMXqIjpS9XQStUbgJEGywV8sy3nHQwsdGVBPQ5G8iLWTici4UeV1ic0YtaR8zMwmWsjMxEUx8pLWIdkS20gVnd3934/iYJp5eTIa5Bp4/CWI7jFPgneseNkfW+Rbrfl7/M0pvFyoIQjXBWLTe+RgAew4PpCJ5pjaU/KXJE41P4bX1aT9M2VOOlI7XFSScwR0ikRK0xJKv6VldHOAH7dHG56wHxKPbJU3SEvP+0rINa3FZDgL2b95K8HwakMy6AGHIgERBipV7sJVEwQwg5QHvBm0hAN7iRI1Se+qN4JkC6DTDzNrTx2khlhS9wEouQ1NlfXpiA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1778181887; bh=GdFbf8sk9rgX4N8X37YmW3aSc8GnjcaQPOJHEJF9f2V=; h=X-Sonic-MF:Date:Subject:From:To:From:Subject; b=nu/o53TIhaen0M/fdh9S5AJG8TV3yox3NClj0Lr9pRtlWWO+Lmj+5r1V4/3bx6WSz46L97MSMBZJCk9XLIvlq4Ceq2mnawG5z67kvN1DK+BF84U2O3lmZVzaS1FnPPohgvv8gDqCwEkVoI2ZorPaLRWHvgcXacml/2EAy0DQNy01W0KOgTvzXkaw3qwikYZOg0j6cg/zRjMfIdImOLjbCOF7AhPC/VliImO3lOiAHx68mmookuDr5/3TcDT/5uhxLNJDIIh0b5Xsn4iaKpBKnDBwiVJcsJRUoNfS0e925saFL8c/v+hk9X4VOCuTQYsNazYjJNN4Hvn7lZN2SqfzTw== X-YMail-OSG: JsDp9F0VM1l0yJnXZHS5.e.yd8btwn0PzHtyoENqnNuCElAYCKgFYswnZm9GVGU wVUY_jB6cnr6MFP7BWs369sxWTxPbDsOG5d.g_qhXEyRFP9sK1oiDfdgOmZiBhighWv2gKF0uleJ nNp67SBsgSbuk0IAsixA_NYPmYZcVwpZDP1tuTy0TzEVstQNrt7UrFtnc_nPKywRxC6X4itItEfw TAKcC8ibtXx4wP3EAfQ91BEr_kwmqL89RbAQDW7e3GEw4YL0SANQASZyCzQ_X57JecN8kjtVD7O_ R_1vJ5hlaAZC4cehBQ035yybbt_i0_0CZsyXNZ.X7zpbn32R5tTtmg0uJwy0TVjw6czZCQ_H7U0t P9mstIZg7k4lQRN0rpLkGVO7JbGJcjE9Cl9HV2kl4yLyM.cCPfSqGB30DjalWDrVcrZ.kbxlbNHQ 2iAyDjGOwMpXbi0ZzkDiAny7Blp2Wyi9RjF2PV0j9u8xkRA.MDBZTnEELbtmglPWoZc3q5Uz3Bbm _u.GOvvubZ9ctam7Th3vTTifsT5CrQ5C4_HdPBwA8jj2brlgV814VhjIz.9wxxkVziHPf0gdOP.5 09KOmnvlrDCvNaHj6ibj8K1rlcVIhupNBGFyjT1L5zxoTBvNdHYMO65nE8w3qcbFIe3axghsxPCN jvCPuK.Mj059rSeTrnYgK61V4tG8E4WKz9OBIWdjYOZ0H2sKFOrCGMlVD_5ozfyWNRwOa6VS8RDi 8QBaIDsnMZ6hHcPvHBT.c1t.apwLT1ejDkTcsjM1KlRpoyxQ_NkG75YB9l7sYErsMuojBobEvRB6 s5XxlwrCVjNB50Vm.CFl4q.QEyC_Als4ME5j1mSHvktXL5gRy2jwmHvd9UsCHAAhACWRRsn.gk0g ZGA.dNxQ6VJDA_sfkddcr.tGdjm2kJHvXFGEdPcMnaA8IJeHHAhphjkqDYrLrDRfTdvzW25vJLMA hj37SkLQX1OtA6HLUqpDCdgFU9G_ntuHkBjNLljyKF3CeKpFoXelCvbI70yw3y0zrTjVWECtZjSK tRZEiVl2QLRA4nu2xk78ohxiUMogiQkJ6ImKhhLmp8DniJQXBW3Avh4rNJeAltnSUqUzR7Ybnrec 0onVVdyR60i6r133K4WZ5XjlaNqgBsW9e95J5V3Z2m3EmQbgsInWSO.J5Db.30OzqNWPnN5xfLrf XEbJLjLU_FriY2Ul2Y0ExSXrOtydCdj.nxDH3DWWiy34NTmQCvKgdfllyRbDtNsM9pcTou2wL0Ca 8VDQx3hk6QRkVUo285mCNK4yIyDFBXezWYHKgZxS4hvGwOxe.EYigOZuaw8QVsUlaP83GYJsNwgW c6bhaXo5S7qM6S.1296Ygd_IC4WaqXaBJvbjCrfDF_hwkodfEnYZy0GKX9h2M8NIPRUKCr6mIkh7 M2P83Dip8DV.rRm7sxTsZmcxuHPEuEZfcCOQPzhGjI7d.oJk03sHXh9nfciehBYJsiVSVxTZdGw9 lB0WzSo2bYbVTQt6YBGIJFaJYTix0aW5v5LumjTvvsK02klj2xxLQhWZlF1d6wg5867XO2yyQh3_ BNbvQVQ0V9IS2jams3ymlXQN1XFFsTDoQDm_KHHrSTew4PDcM_msl2MFzvOqv8CBOnjIADR4HORo 7KGuPZahjQ9E_EGezQ0x_tE7FMDCjL1DMH_YEnlPGIma8BM3hZzrrbWuZtCcis4TuLkmVzZRpBky Z_W6N4avIFCsgruqg1SeC0ZOXVVQOjYIUNmU0ZLCwwXYu4zcHkcLdi7GWvDOdxucRbyvpdGGZFH6 h3hz8eDEt8MvKTuSntIvTgLMBoQcl6Q_4JP.4MOYppOEli6rl_QPms0ygW4WG1cb1v4ImCNyGIIM 6fwffLL6E2nvlE50XAfOWqMmqp4tiQpVWbGtVtQYV9c9pc36e0foZh6w91bEumzt5puhmKPygtY5 vjPWauWL_4ePaSN5KTAFlovsfWdotPLSxXk5RXo1SbLxsGwezUEYkmrTWTnYiOIUVRVm33FvcDoA .PkePCJ0kfJsepOSuJk0qjHhu4cO7PdSZ_6.GQEd_R2zBg1tgW0pVP6VK2RjtPydFk..Zxgo9MGI xE2jLuULq4qugACA9je.QYtuFdIFcXch0qcCn_O_cAKdA5ZX0znNM1ZPd37NHKJfklNIpoDgSlUs ZHSr1MkNJV_PDsq2ooh4EYtUHDAlO3MBhZTbS7qtMyxprzRxaPZVEHJhodCViGWtduHOmTB77MWL Zp.BeTJRsvV79DEHvzFteauZl0XmFE_Vh1b4g1JlgWr3HWxEmoIjrMTJgroKBD8Ay8gQwcto5Z9L 2XflJqIgOj2j4W75uclSOWhxq9tgPFNwUn_dXQ9NQwADPk0AiYw94Qx3SybemmC_0M1lO X-Sonic-MF: X-Sonic-ID: ee7a9984-00b6-4b2c-ae5c-fb72336b7294 Received: from sonic.gate.mail.ne1.yahoo.com by sonic311.consmr.mail.gq1.yahoo.com with HTTP; Thu, 7 May 2026 19:24:47 +0000 Received: by hermes--production-gq1-7bb7df5c46-m46kc (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 51890767359679f09e7c00966d7cf041; Thu, 07 May 2026 19:24:43 +0000 (UTC) Message-ID: Date: Thu, 7 May 2026 12:24:41 -0700 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: ar: error: libclang.a: 'ParseDecl.o': section header table goes past EOF [Looks to be: armv7 llvm19 fails to build bootstrap llvm21] From: Mark Millard To: bob prohaska Cc: freebsd-current@freebsd.org, dim@FreeBSD.org Newsgroups: gmane.os.freebsd.current References: <2c2ab68d-83eb-4b6d-996d-10c2169a2165@yahoo.com> <4fab914f-ff17-4312-a098-975b6c103e05@yahoo.com> <413d71d1-6e18-4c7f-8844-d85c304d0504@yahoo.com> <33436574-0b2b-4db8-a69f-85df46af12a6@yahoo.com> <7e29fc11-9fcc-4a71-97bb-b709862e35e1@yahoo.com> Content-Language: en-US In-Reply-To: <7e29fc11-9fcc-4a71-97bb-b709862e35e1@yahoo.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailer: WebService/1.1.25559 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.yahoo X-Spamd-Result: default: False [-3.53 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-0.998]; NEURAL_HAM_SHORT(-0.54)[-0.537]; 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]; RCVD_TLS_LAST(0.00)[]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; TO_DN_SOME(0.00)[]; MIME_TRACE(0.00)[0:+]; 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.65.205:from]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.65.205:from]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim] X-Spamd-Bar: --- X-Rspamd-Queue-Id: 4gBMdZ2ffCz47Wm On 5/7/26 09:05, Mark Millard wrote: > On 5/6/26 19:59, Mark Millard wrote: >> On 5/6/26 09:07, bob prohaska wrote: >>> On Wed, May 06, 2026 at 08:54:32AM -0700, Mark Millard wrote: >>>> On 5/6/26 07:50, bob prohaska wrote: >>>>> On Tue, May 05, 2026 at 09:59:02PM -0700, Mark Millard wrote: >>>>>> On 5/5/26 17:32, bob prohaska wrote: >>>>>>> On Tue, May 05, 2026 at 11:37:12AM -0700, Mark Millard wrote: >>>>>>>> On 5/5/26 07:48, bob prohaska wrote: >>>>>>>>> A Pi2B (armv7) is failing buildworld with: >> >> Which is true of the context: >> >> ) Is the old system one still using the llvm19 based clang related >> toolchain --so that the build needs to bootstrap the llvm21 based >> one? >> vs. >> ) Is the old system one already using the new llvm21 based clang-related >> toolchain --so that no bootstrap toolchain is needed (even if one is >> being built)? >> >>>>>>>>> >>>>>>>>> Building static clang library >>>>>>>>> ar: error: libclang.a: 'ParseDecl.o': section header table goes past the end of >>>>>>>>> the file: e_shoff = 0x131190 >>>>>> >>>>>> How big is the ParseDecl.o file that gets this report? >>>>>> >>>>>> >>>>> >>>>> # ls -l /usr/obj/usr/src/arm.armv7/tmp/obj-tools/lib/clang/libclang/Parse/ParseDecl.o >>>>> -rw-r--r-- 1 root wheel 393216 May 3 19:15 /usr/obj/usr/src/arm.armv7/tmp/obj-tools/lib/clang/libclang/Parse/ParseDecl.o >>>> >>>> That earlier 0x131190 was a offset in the file. 0x131190 == 1249680 . >>>> That is a lot bigger than 393216. >>>> >>>>> >>>>>> >>>>>> (Note the tmp/ in that path. Also the <> usage is in hopes of forming >>>>>> one long line and are not part of the file path.) >>>>>> >>>>> Including the < and > in the pathname triggered a syntax error. Likely I >>>>> misundersood the tip or I'm using a different shell. >>>> >>>> Only use the text inside the <>'s. >>>> >>>> The <>'s are an attempt to prevent the message I send from splitting the >>>> long text into more than one line in the process --even if I do not >>>> split it myself. Otherwise you might have to splice together the full >>>> path. Adding spaces just inside the <>'s would not work for the purpose, >>>> thus the lack of such spaces. >>> Ahhh, so user escapes, not shell escapes 8-) >>> >>>>> >>>>> >>>>>> >>>>>> Can you publish the content of the file: >>>>>> >>>>>> >>>>> >>>>> The file has been placed at >>>>> http://www.zefox.net/~fbsd/rpi2/20260506/ >>>> >>>> You published ParseDecl.o instead of publishing Parse_ParseDecl.o.meta . >>>> >>>> Parse_ParseDecl.o.meta is a text file produced by use of META_MODE . I >>>> expect it will include the text of the command that produced >>>> ParseDecl.o . >>>> >>>> Like earlier: omit the <> characters when extracting the path. >>>> >>> Apologies for the blunder! The correct file is now at: >>> http://www.zefox.net/~fbsd/rpi2/20260506/Parse_ParseDecl.o.meta >>> >>> Thanks for writing, and your patience! >>> >>> bob prohaska >>> >>> >> >> My guess is that, for an initially empty build tree in a armv7 context, >> a command sequence like: >> >> # cd /usr/src/ >> # env WITH_META_MODE= \ >> make -j3 \ >> WITHOUT_SYSTEM_COMPILER= \ >> WITHOUT_SYSTEM_LINKER= \ >> kernel-toolchain >> >> may be sufficient to have: >> >> >> >> generated instead of skipped, via avoiding use of the system >> compiler/linker, even if they are llvm21 based already. (In my >> context they are llvm21 based, as it is a preexisting upstream pkgbase >> distribution install from after llvm21 was updated that is doing the build.) >> >> I have such a llvm21-context build going in an armv7 chroot (in a >> context were -j8 is reasonable). Still, it is going to be some time >> before I know if the build repeated the problem vs. not. >> >> It may be that one has to start with an llvm19-based context to see the >> problem. I do not have such a llvm19 context available. >> >> > > Bob sent Email that was not sent to the list that reported his context > upgrade context is starting with an environment that has: > > QUOTE > Clang -v reports > FreeBSD clang version 19.1.7 (https://github.com/llvm/llvm-project.git > llvmorg-19.1.7-0-gcd708029e0b2) > Target: armv7-unknown-freebsd16.0-gnueabihf > Thread model: posix > InstalledDir: /usr/bin > Build config: +assertions > END QUOTE > > My test case was llvm21 based, no bootsrap needed --but when Iforced a > boostrap, llvm21 boostrapped itself just fine. > > Thus, it looks like the armv7 llvm19 context has a problem that prevents > source code building the llvm21 bootstrap context correctly. > > > At this time I do not have an armv7 llvm19 based context to > independently test. > > [dim@ may be interested in this point:] I will note that the in-progress 15.1-RELEASE is based on the llvm19 related toolchain. So, later when, say, 15.2-RELEASE tries to be based on llvm21 (or later) instead, this problem for armv7 may well repeat in the official release sequence. As for main, I now have a chroot based on: which is old enough to be llvm19 based. It is attempting a kernel-toolchain build based on building: # ~/fbsd-based-on-what-commit.sh -C /usr/src-alt/ 839d3266d8c6 (HEAD -> main, freebsd/main, freebsd/HEAD) uipc_shm.c: make large page allocation interruptible Author: Konstantin Belousov Commit: Konstantin Belousov CommitDate: 2026-05-01 01:06:42 +0000 branch: main merge-base: 839d3266d8c6f6471cb92a3c0ae32eb16d117427 merge-base: CommitDate: 2026-05-01 01:06:42 +0000 n285621 (--first-parent --count for merge-base) We will see what it does for: tmp/obj-tools/lib/clang/libclang/Parse/ParseDecl.o -- === Mark Millard marklmi at yahoo.com From nobody Thu May 7 19:24:41 2026 X-Original-To: freebsd-current@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 4gBMdb6kFPz6d3Vm for ; Thu, 07 May 2026 19:24:51 +0000 (UTC) (envelope-from freebsd-current@m.gmane-mx.org) Received: from ciao.gmane.io (ciao.gmane.io [116.202.254.214]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (prime256v1) server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4gBMdY4l6bz47cN for ; Thu, 07 May 2026 19:24:49 +0000 (UTC) (envelope-from freebsd-current@m.gmane-mx.org) Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=yahoo.com (policy=reject); spf=pass (mx1.freebsd.org: domain of freebsd-current@m.gmane-mx.org designates 116.202.254.214 as permitted sender) smtp.mailfrom=freebsd-current@m.gmane-mx.org Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1wL4L1-0007Aw-NX for freebsd-current@freebsd.org; Thu, 07 May 2026 21:24:47 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: Mark Millard Subject: Re: ar: error: libclang.a: 'ParseDecl.o': section header table goes past EOF [Looks to be: armv7 llvm19 fails to build bootstrap llvm21] Date: Thu, 7 May 2026 12:24:41 -0700 Message-ID: References: <2c2ab68d-83eb-4b6d-996d-10c2169a2165@yahoo.com> <4fab914f-ff17-4312-a098-975b6c103e05@yahoo.com> <413d71d1-6e18-4c7f-8844-d85c304d0504@yahoo.com> <33436574-0b2b-4db8-a69f-85df46af12a6@yahoo.com> <7e29fc11-9fcc-4a71-97bb-b709862e35e1@yahoo.com> List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit User-Agent: Mozilla Thunderbird Cc: freebsd-current@freebsd.org, dim@FreeBSD.org Content-Language: en-US In-Reply-To: <7e29fc11-9fcc-4a71-97bb-b709862e35e1@yahoo.com> X-Spamd-Result: default: False [3.69 / 15.00]; DMARC_POLICY_REJECT(2.00)[yahoo.com : SPF not aligned (relaxed), No valid DKIM,reject]; NEURAL_SPAM_MEDIUM(0.99)[0.990]; NEURAL_SPAM_SHORT(0.83)[0.832]; NEURAL_HAM_LONG(-0.83)[-0.829]; MV_CASE(0.50)[]; FORGED_SENDER(0.30)[marklmi@yahoo.com,freebsd-current@m.gmane-mx.org]; R_SPF_ALLOW(-0.20)[+mx]; ONCE_RECEIVED(0.20)[]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; TO_DN_NONE(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; RCPT_COUNT_THREE(0.00)[3]; ASN(0.00)[asn:24940, ipnet:116.202.0.0/16, country:DE]; R_DKIM_NA(0.00)[]; RCVD_COUNT_ONE(0.00)[1]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; FROM_NEQ_ENVFROM(0.00)[marklmi@yahoo.com,freebsd-current@m.gmane-mx.org] X-Spamd-Bar: +++ X-Rspamd-Queue-Id: 4gBMdY4l6bz47cN On 5/7/26 09:05, Mark Millard wrote: > On 5/6/26 19:59, Mark Millard wrote: >> On 5/6/26 09:07, bob prohaska wrote: >>> On Wed, May 06, 2026 at 08:54:32AM -0700, Mark Millard wrote: >>>> On 5/6/26 07:50, bob prohaska wrote: >>>>> On Tue, May 05, 2026 at 09:59:02PM -0700, Mark Millard wrote: >>>>>> On 5/5/26 17:32, bob prohaska wrote: >>>>>>> On Tue, May 05, 2026 at 11:37:12AM -0700, Mark Millard wrote: >>>>>>>> On 5/5/26 07:48, bob prohaska wrote: >>>>>>>>> A Pi2B (armv7) is failing buildworld with: >> >> Which is true of the context: >> >> ) Is the old system one still using the llvm19 based clang related >> toolchain --so that the build needs to bootstrap the llvm21 based >> one? >> vs. >> ) Is the old system one already using the new llvm21 based clang-related >> toolchain --so that no bootstrap toolchain is needed (even if one is >> being built)? >> >>>>>>>>> >>>>>>>>> Building static clang library >>>>>>>>> ar: error: libclang.a: 'ParseDecl.o': section header table goes past the end of >>>>>>>>> the file: e_shoff = 0x131190 >>>>>> >>>>>> How big is the ParseDecl.o file that gets this report? >>>>>> >>>>>> >>>>> >>>>> # ls -l /usr/obj/usr/src/arm.armv7/tmp/obj-tools/lib/clang/libclang/Parse/ParseDecl.o >>>>> -rw-r--r-- 1 root wheel 393216 May 3 19:15 /usr/obj/usr/src/arm.armv7/tmp/obj-tools/lib/clang/libclang/Parse/ParseDecl.o >>>> >>>> That earlier 0x131190 was a offset in the file. 0x131190 == 1249680 . >>>> That is a lot bigger than 393216. >>>> >>>>> >>>>>> >>>>>> (Note the tmp/ in that path. Also the <> usage is in hopes of forming >>>>>> one long line and are not part of the file path.) >>>>>> >>>>> Including the < and > in the pathname triggered a syntax error. Likely I >>>>> misundersood the tip or I'm using a different shell. >>>> >>>> Only use the text inside the <>'s. >>>> >>>> The <>'s are an attempt to prevent the message I send from splitting the >>>> long text into more than one line in the process --even if I do not >>>> split it myself. Otherwise you might have to splice together the full >>>> path. Adding spaces just inside the <>'s would not work for the purpose, >>>> thus the lack of such spaces. >>> Ahhh, so user escapes, not shell escapes 8-) >>> >>>>> >>>>> >>>>>> >>>>>> Can you publish the content of the file: >>>>>> >>>>>> >>>>> >>>>> The file has been placed at >>>>> http://www.zefox.net/~fbsd/rpi2/20260506/ >>>> >>>> You published ParseDecl.o instead of publishing Parse_ParseDecl.o.meta . >>>> >>>> Parse_ParseDecl.o.meta is a text file produced by use of META_MODE . I >>>> expect it will include the text of the command that produced >>>> ParseDecl.o . >>>> >>>> Like earlier: omit the <> characters when extracting the path. >>>> >>> Apologies for the blunder! The correct file is now at: >>> http://www.zefox.net/~fbsd/rpi2/20260506/Parse_ParseDecl.o.meta >>> >>> Thanks for writing, and your patience! >>> >>> bob prohaska >>> >>> >> >> My guess is that, for an initially empty build tree in a armv7 context, >> a command sequence like: >> >> # cd /usr/src/ >> # env WITH_META_MODE= \ >> make -j3 \ >> WITHOUT_SYSTEM_COMPILER= \ >> WITHOUT_SYSTEM_LINKER= \ >> kernel-toolchain >> >> may be sufficient to have: >> >> >> >> generated instead of skipped, via avoiding use of the system >> compiler/linker, even if they are llvm21 based already. (In my >> context they are llvm21 based, as it is a preexisting upstream pkgbase >> distribution install from after llvm21 was updated that is doing the build.) >> >> I have such a llvm21-context build going in an armv7 chroot (in a >> context were -j8 is reasonable). Still, it is going to be some time >> before I know if the build repeated the problem vs. not. >> >> It may be that one has to start with an llvm19-based context to see the >> problem. I do not have such a llvm19 context available. >> >> > > Bob sent Email that was not sent to the list that reported his context > upgrade context is starting with an environment that has: > > QUOTE > Clang -v reports > FreeBSD clang version 19.1.7 (https://github.com/llvm/llvm-project.git > llvmorg-19.1.7-0-gcd708029e0b2) > Target: armv7-unknown-freebsd16.0-gnueabihf > Thread model: posix > InstalledDir: /usr/bin > Build config: +assertions > END QUOTE > > My test case was llvm21 based, no bootsrap needed --but when Iforced a > boostrap, llvm21 boostrapped itself just fine. > > Thus, it looks like the armv7 llvm19 context has a problem that prevents > source code building the llvm21 bootstrap context correctly. > > > At this time I do not have an armv7 llvm19 based context to > independently test. > > [dim@ may be interested in this point:] I will note that the in-progress 15.1-RELEASE is based on the llvm19 related toolchain. So, later when, say, 15.2-RELEASE tries to be based on llvm21 (or later) instead, this problem for armv7 may well repeat in the official release sequence. As for main, I now have a chroot based on: which is old enough to be llvm19 based. It is attempting a kernel-toolchain build based on building: # ~/fbsd-based-on-what-commit.sh -C /usr/src-alt/ 839d3266d8c6 (HEAD -> main, freebsd/main, freebsd/HEAD) uipc_shm.c: make large page allocation interruptible Author: Konstantin Belousov Commit: Konstantin Belousov CommitDate: 2026-05-01 01:06:42 +0000 branch: main merge-base: 839d3266d8c6f6471cb92a3c0ae32eb16d117427 merge-base: CommitDate: 2026-05-01 01:06:42 +0000 n285621 (--first-parent --count for merge-base) We will see what it does for: tmp/obj-tools/lib/clang/libclang/Parse/ParseDecl.o -- === Mark Millard marklmi at yahoo.com From nobody Thu May 7 21:33:13 2026 X-Original-To: freebsd-current@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 4gBQTs65Pdz6c1fg for ; Thu, 07 May 2026 21:33:21 +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 4gBQTq2VBvz3XyD for ; Thu, 07 May 2026 21:33:19 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=bD3hNUkl; 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=1778189595; bh=gr5XPMby40+73MZJ8JjBH60WmX9xdyhO5lrCbXAgGR0=; h=Date:Subject:From:To:Cc:References:In-Reply-To:From:Subject:Reply-To; b=bD3hNUklxjuPQnObaYfESKZAcK/Nd13DKVpJ+VjYRFSHd3U6wusSaFdO4N+PG7CSZRKvjUdg7MPSqVXo8Vz7ySvOp77s2UiBvFruFuRY/ZItrxnvJyS1/Vmks41TL9hgMkstwSyT2EZnfDj0/kJ5vvP3sdE3kBvsNgeTncuw+HEgsFWK8yqUcuc10n8srXSS2GK/Av/hJr7W5nSEb1e5+HJIPEIgt1zRKjCJGFrOkrSsgWnuKSdhfkNRHh1imtEOWYx35EK/PLZoV617ey7zNLUdIJBOW5pHBbOCtlyqVpiASrixAlxl6BSQxhBSIXUUmbSbBTF5RRbQHqr1KTvIYg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1778189595; bh=jK5MdFPwgPS+VBOZWeFUQtUUZBOHfcBWf3mfIelJB/W=; h=X-Sonic-MF:Date:Subject:From:To:From:Subject; b=j9MJZAfwmYgCb1xk9Uf1yDiSeHAJ1IIoR77DoGn+NkQQMJafzHNoHqqBxb6ycl65FXHMTI5RiZlEgKyEmfwASd8C17UnlT85xhoMsRuPQ8udfXwFYt7tzLH0kAPIZ4pg5RbPL3Ch4qhMn6z7x0WkF7fthXttR1fT8WUCIlMpQdPFKTqgTI9EPSflUkjYtfO2AiiR1Pp9Gnx8KLGhvzELX5RMZOesdoLOAC3l4CG3fu7diOlRaEnPQ+VPxYzqQxZkRKZziMq+Dwu+bPqhLLkJNzw8Ezv8Q6vg2sRSOmDIkus9evq0T8ugjCt4195FvTDGEB2J4h5wCSOtcrSjnwQe5A== X-YMail-OSG: vqi_mngVM1nWPulW9zIB2G9wLsS.Nlmd8GKKnWGqvmu10q5ta3EIkYGkCqffTCx CvzYaYrfmJ9GwXubfwXFCGUI2VnmuC3vAemYy3DDAPC6JHyrISI9fvtT2x0Q4gJJ6kdDuibVt5By Pu7PJO85mRu3j.mjKRgmVgnekqLy0PQwcpbyyVHiT3s4FGMzcxEQ_oUf0kg.c5_1uo47vKL_VM2A 8zRmgNup305trfFH5_79aQuzIfRfGybY5anU6_p5OXbw5hhvICekYr0cKRohd9JF_7x6Op_qRn9e UTokgdtNjmy0kjfR4FeOncnv7JkLnt6sEBQmK_E75BVMFCtKaKFaK6lUutNs8MH9TpYVWIaxicvu GE1hLdF5vGnCJQq.CcW1huXqUaqf2..2lTqS5gqEEHrgvKT3KUbBbQbl3Ym1jnasY7lm6mCrO4Hc 5sbijLwcVdr.5ZHfWCJMSrdPSeZID_YU9_gNszCr.oQe8ZRl.LnYZJV7wS4NH_RcBWQ.jgY6ZXC1 2QqVG.J0qNN6ZFgm7W7mclPHjcGbrUxdJWH8xZSEZi_XCVxWg88Vf9AqCEHsfzOU4L.M38kAJf_J nz0ffiy4ED.y524vK_82qF_Ip53Ip9gAht6YOsLAIFCQofSpcs4PoarHRREK5_i_9kIKSN7v6I0w rCghPkW3E0lqacp9lI5TTmLkgAbn8gweq22ikawjcaEgxOLPD59UaCzlxclM5HH50HTLCaD_k5Mw LBlHWMjTUumhBCDwbjXw7VmGcOLwkziwinFCsC8WZjxPNX4lnmRB9wSp95SeLDM9McKpVv8P0sSX mZ15ZmPFNLYZecvaNI0kk3z1jgq8DRWA4kFoe5bkWeVBa68ybv8jtrwWNc3YRx6lDGUZn4XsVNJv jdUF9nH9waGpygb50GLF0Pv9DzU4o2Ccg3NI6fSKwewP6I5QLs3v5WCBxJyqJWioz.qEiz3HyvGz juTe6qofzf6PrP5Hn6g72CJN7SJJhNWSyOvSQI8MxenUIagENdGOqsx6QhkfA_u.5i3bN4GgzMNN _PjtzCmE8ChIj_qHHMI67aNzuirauTmNL6tZ6cKhEgZQb9LxEk.Go8Ei0t4rgGMKefcF384rOCFu _RJ12oNnOZCIDWI6yVpVHkMj_qWduE7VZq4zLqYt8X_DWhCSDrynOXQqND_Yc4eWC9qxu9gwk23h XgcDdMutQH.cmBhVzk1yfdt3YxvkjC4Ydcz42yLyucGJgoClu0_nWclhyZhuiy6VANMXUTP7Bd8o tQMxDs58_6i07OJGkBeeyXzi1R4YQ7mOgF8r2_CF04T5MKNMYBC6A5qvxzrHrFfX_pLkX5qOAVH3 kTSYrTNLrj5J3u9E5p1cbbOq0n1NTghPQ9ViGms3UoySb5XnabkaaLoHwH04hDhncI9gNBmh77pJ z6lTgjx_iv5uiIVsoZFvEIvS7YCMharPNnAS7ijWBI_wNSjkWgKDswk_bb8WS6Lw.3J3hFY0uTJ_ 16b0e5zVz3Y8j0rdzkXMsdTG1AIiK.LllPjHyNo365.eWDinpeS6wmRgcH7_ESpeZHF9LhglCLG8 GGxgqIrHBoN2OdDWiWdc.SzLTkYoCzBs5mNu9avB6j3CPXAzJZQAxTd4g7HSo6qoqdJSqr3Lf39B kRzrbEJqT421IqmwfZ5a93n9DRPwda4AWSECHUnhLJfqmPk1dscif24hynG.LDk8ZKYqmmxAnFdw .ZizqhyQSlZQIUlmmGryJciyolKBEBkJQmCma_FG683ZHRdD0H0Q1T2Ugeo4bz8WUqBavJkjz6er KglhXCbAn1k3nUomp8PE7iMxYm3tu56mgcgDyws8N5YhOTKmKHaQWU5cX1_HyXu7WQqA8VwdjkRS jNqCXpmjOuDeEz0kD7eDdSRFDgo_S6t7l5Qh2hI14BcwBL6MBNT375cavw9mtVXcnPfTxBdOZ3.J MGs7KszSCGNNM5Z1O_SqXvkfatJP1HTMBnTdesQ7oeZOevy0DRRcyYDmbE9Z_DvYe7j0RTiuK8uh 9_fM7qjLBinjMHC8H8tT6yVzvtTeboMPn3PPMHcX_p2mlEf.wtQXNY4i8QggGlOnbqMldVKebWVk Bvjlm2TsUqu9Ivy1_Stxvqx61SLFXacE9oP3S7yH8_CBtzo7.9RMEOXlwyItcb5FD2PYpGrJzfIk FLgXKEqMGsKKyXMbF.E6lo.78v4T0znn0djIrnIqu9__4ePZII8_3t3HAcC7jUV_HfVRa4YvU9wn XITj92RpPPwvQFy5vh.RSMlakw842NkMml2dCwrVZ9fIkykpzjZDoElcUHMXgNbTKJ9tbfsJoK_x UP9vo6LHYVBJfJ7IZ X-Sonic-MF: X-Sonic-ID: fae8578e-7c06-4ed5-bd9d-7e2c9210242e Received: from sonic.gate.mail.ne1.yahoo.com by sonic317.consmr.mail.gq1.yahoo.com with HTTP; Thu, 7 May 2026 21:33:15 +0000 Received: by hermes--production-gq1-7bb7df5c46-2m55j (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 260def5a76c78cdbfa26ec578540b2a6; Thu, 07 May 2026 21:33:14 +0000 (UTC) Message-ID: <9ff7855f-2b48-4cac-a82d-2cbd9912dc27@yahoo.com> Date: Thu, 7 May 2026 14:33:13 -0700 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: ar: error: libclang.a: 'ParseDecl.o': section header table goes past EOF [So far: unable to reproduce, even based on llvm19 involvement] From: Mark Millard To: bob prohaska Cc: freebsd-current@freebsd.org, dim@FreeBSD.org References: <2c2ab68d-83eb-4b6d-996d-10c2169a2165@yahoo.com> <4fab914f-ff17-4312-a098-975b6c103e05@yahoo.com> <413d71d1-6e18-4c7f-8844-d85c304d0504@yahoo.com> <33436574-0b2b-4db8-a69f-85df46af12a6@yahoo.com> <7e29fc11-9fcc-4a71-97bb-b709862e35e1@yahoo.com> Content-Language: en-US In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailer: WebService/1.1.25559 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.yahoo X-Spamd-Result: default: False [-3.99 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.99)[-0.986]; 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]; RCVD_TLS_LAST(0.00)[]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; TO_DN_SOME(0.00)[]; MIME_TRACE(0.00)[0:+]; 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]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.66.147:from]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.66.147:from] X-Spamd-Bar: --- X-Rspamd-Queue-Id: 4gBQTq2VBvz3XyD On 5/7/26 12:24, Mark Millard wrote: > On 5/7/26 09:05, Mark Millard wrote: >> On 5/6/26 19:59, Mark Millard wrote: >>> On 5/6/26 09:07, bob prohaska wrote: >>>> On Wed, May 06, 2026 at 08:54:32AM -0700, Mark Millard wrote: >>>>> On 5/6/26 07:50, bob prohaska wrote: >>>>>> On Tue, May 05, 2026 at 09:59:02PM -0700, Mark Millard wrote: >>>>>>> On 5/5/26 17:32, bob prohaska wrote: >>>>>>>> On Tue, May 05, 2026 at 11:37:12AM -0700, Mark Millard wrote: >>>>>>>>> On 5/5/26 07:48, bob prohaska wrote: >>>>>>>>>> A Pi2B (armv7) is failing buildworld with: >>> >>> Which is true of the context: >>> >>> ) Is the old system one still using the llvm19 based clang related >>> toolchain --so that the build needs to bootstrap the llvm21 based >>> one? >>> vs. >>> ) Is the old system one already using the new llvm21 based clang-related >>> toolchain --so that no bootstrap toolchain is needed (even if one is >>> being built)? >>> >>>>>>>>>> >>>>>>>>>> Building static clang library >>>>>>>>>> ar: error: libclang.a: 'ParseDecl.o': section header table goes past the end of >>>>>>>>>> the file: e_shoff = 0x131190 >>>>>>> >>>>>>> How big is the ParseDecl.o file that gets this report? >>>>>>> >>>>>>> >>>>>> >>>>>> # ls -l /usr/obj/usr/src/arm.armv7/tmp/obj-tools/lib/clang/libclang/Parse/ParseDecl.o >>>>>> -rw-r--r-- 1 root wheel 393216 May 3 19:15 /usr/obj/usr/src/arm.armv7/tmp/obj-tools/lib/clang/libclang/Parse/ParseDecl.o >>>>> >>>>> That earlier 0x131190 was a offset in the file. 0x131190 == 1249680 . >>>>> That is a lot bigger than 393216. >>>>> >>>>>> >>>>>>> >>>>>>> (Note the tmp/ in that path. Also the <> usage is in hopes of forming >>>>>>> one long line and are not part of the file path.) >>>>>>> >>>>>> Including the < and > in the pathname triggered a syntax error. Likely I >>>>>> misundersood the tip or I'm using a different shell. >>>>> >>>>> Only use the text inside the <>'s. >>>>> >>>>> The <>'s are an attempt to prevent the message I send from splitting the >>>>> long text into more than one line in the process --even if I do not >>>>> split it myself. Otherwise you might have to splice together the full >>>>> path. Adding spaces just inside the <>'s would not work for the purpose, >>>>> thus the lack of such spaces. >>>> Ahhh, so user escapes, not shell escapes 8-) >>>> >>>>>> >>>>>> >>>>>>> >>>>>>> Can you publish the content of the file: >>>>>>> >>>>>>> >>>>>> >>>>>> The file has been placed at >>>>>> http://www.zefox.net/~fbsd/rpi2/20260506/ >>>>> >>>>> You published ParseDecl.o instead of publishing Parse_ParseDecl.o.meta . >>>>> >>>>> Parse_ParseDecl.o.meta is a text file produced by use of META_MODE . I >>>>> expect it will include the text of the command that produced >>>>> ParseDecl.o . >>>>> >>>>> Like earlier: omit the <> characters when extracting the path. >>>>> >>>> Apologies for the blunder! The correct file is now at: >>>> http://www.zefox.net/~fbsd/rpi2/20260506/Parse_ParseDecl.o.meta >>>> >>>> Thanks for writing, and your patience! >>>> >>>> bob prohaska >>>> >>>> >>> >>> My guess is that, for an initially empty build tree in a armv7 context, >>> a command sequence like: >>> >>> # cd /usr/src/ >>> # env WITH_META_MODE= \ >>> make -j3 \ >>> WITHOUT_SYSTEM_COMPILER= \ >>> WITHOUT_SYSTEM_LINKER= \ >>> kernel-toolchain >>> >>> may be sufficient to have: >>> >>> >>> >>> generated instead of skipped, via avoiding use of the system >>> compiler/linker, even if they are llvm21 based already. (In my >>> context they are llvm21 based, as it is a preexisting upstream pkgbase >>> distribution install from after llvm21 was updated that is doing the build.) >>> >>> I have such a llvm21-context build going in an armv7 chroot (in a >>> context were -j8 is reasonable). Still, it is going to be some time >>> before I know if the build repeated the problem vs. not. >>> >>> It may be that one has to start with an llvm19-based context to see the >>> problem. I do not have such a llvm19 context available. >>> >>> >> >> Bob sent Email that was not sent to the list that reported his context >> upgrade context is starting with an environment that has: >> >> QUOTE >> Clang -v reports >> FreeBSD clang version 19.1.7 (https://github.com/llvm/llvm-project.git >> llvmorg-19.1.7-0-gcd708029e0b2) >> Target: armv7-unknown-freebsd16.0-gnueabihf >> Thread model: posix >> InstalledDir: /usr/bin >> Build config: +assertions >> END QUOTE >> >> My test case was llvm21 based, no bootsrap needed --but when Iforced a >> boostrap, llvm21 boostrapped itself just fine. >> >> Thus, it looks like the armv7 llvm19 context has a problem that prevents >> source code building the llvm21 bootstrap context correctly. >> >> >> At this time I do not have an armv7 llvm19 based context to >> independently test. >> >> > > [dim@ may be interested in this point:] > I will note that the in-progress 15.1-RELEASE is based on the llvm19 > related toolchain. So, later when, say, 15.2-RELEASE tries to be based > on llvm21 (or later) instead, this problem for armv7 may well repeat in > the official release sequence. > > > As for main, I now have a chroot based on: > > > > which is old enough to be llvm19 based. It is attempting a > kernel-toolchain build based on building: > > # ~/fbsd-based-on-what-commit.sh -C /usr/src-alt/ > 839d3266d8c6 (HEAD -> main, freebsd/main, freebsd/HEAD) uipc_shm.c: make > large page allocation interruptible > Author: Konstantin Belousov > Commit: Konstantin Belousov > CommitDate: 2026-05-01 01:06:42 +0000 > branch: main > merge-base: 839d3266d8c6f6471cb92a3c0ae32eb16d117427 > merge-base: CommitDate: 2026-05-01 01:06:42 +0000 > n285621 (--first-parent --count for merge-base) > > We will see what it does for: > > tmp/obj-tools/lib/clang/libclang/Parse/ParseDecl.o > > My attempt at reproducing the problem (small ParseDecl.o file) still got the full sized ParseDecl.o result (1295860): # ls -lodT /usr/obj/usr/src-alt/arm.armv7/tmp/obj-tools/lib/clang/libclang/Parse/ParseDecl.o -rw-r--r-- 1 root wheel - 1295860 May 7 13:16:25 2026 /usr/obj/usr/src-alt/arm.armv7/tmp/obj-tools/lib/clang/libclang/Parse/ParseDecl.o This was based on an environment doing the build that has: # clang -v FreeBSD clang version 19.1.7 (https://github.com/llvm/llvm-project.git llvmorg-19.1.7-0-gcd708029e0b2) Target: armv7-unknown-freebsd16.0-gnueabihf Thread model: posix InstalledDir: /usr/bin Build config: +assertions # ~/fbsd-based-on-what-commit.sh -C /usr/src-alt/ 839d3266d8c6 (HEAD -> main, freebsd/main, freebsd/HEAD) uipc_shm.c: make large page allocation interruptible Author: Konstantin Belousov Commit: Konstantin Belousov CommitDate: 2026-05-01 01:06:42 +0000 branch: main merge-base: 839d3266d8c6f6471cb92a3c0ae32eb16d117427 merge-base: CommitDate: 2026-05-01 01:06:42 +0000 n285621 (--first-parent --count for merge-base) I diff'd the c++ command from the .meta files and only found the "-alt" used in /usr/src-alt/ references in my context. Removing the -alt examples from my text found no command differences as a result. Complete .meta file comparisons also found process ID differences and time differences but otherwise matched. I still have no clue what is going on in your environment that leads to the small ParseDecl.o file. How old is your environment that is using llvm19? What commit is it based on? -- === Mark Millard marklmi at yahoo.com From nobody Thu May 7 23:46:59 2026 X-Original-To: freebsd-current@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 4gBTRl3Sh3z6cCdj for ; Thu, 07 May 2026 23:46:43 +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 "pelorus.zefox.org", Issuer "pelorus.zefox.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4gBTRk3trHz3pGB; Thu, 07 May 2026 23:46:42 +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.18.1/8.18.1) with ESMTPS id 647Nl6K2082747 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Thu, 7 May 2026 16:47:10 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.18.1/8.18.1/Submit) id 647Nl41x082744; Thu, 7 May 2026 16:47:04 -0700 (PDT) (envelope-from fbsd) Date: Thu, 7 May 2026 16:46:59 -0700 From: bob prohaska To: Mark Millard Cc: freebsd-current@freebsd.org, dim@freebsd.org Subject: Re: ar: error: libclang.a: 'ParseDecl.o': section header table goes past EOF [So far: unable to reproduce, even based on llvm19 involvement] Message-ID: References: <2c2ab68d-83eb-4b6d-996d-10c2169a2165@yahoo.com> <4fab914f-ff17-4312-a098-975b6c103e05@yahoo.com> <413d71d1-6e18-4c7f-8844-d85c304d0504@yahoo.com> <33436574-0b2b-4db8-a69f-85df46af12a6@yahoo.com> <7e29fc11-9fcc-4a71-97bb-b709862e35e1@yahoo.com> <9ff7855f-2b48-4cac-a82d-2cbd9912dc27@yahoo.com> List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9ff7855f-2b48-4cac-a82d-2cbd9912dc27@yahoo.com> 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: 4gBTRk3trHz3pGB X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated On Thu, May 07, 2026 at 02:33:13PM -0700, Mark Millard wrote: > > How old is your environment that is using llvm19? What commit is it > based on? Not sure I understand all of what you're asking. The system reports # uname -apKU FreeBSD pelorus.zefox.org 16.0-CURRENT FreeBSD 16.0-CURRENT #37 main-n285410-c0c7d1e1af4e: Thu Apr 30 07:36:49 PDT 2026 bob@pelorus.zefox.org:/usr/obj/usr/src/arm.armv7/sys/GENERIC arm armv7 1600016 1600016 Apart from setting up meta mode no intentional changes have been made. Buildworld runs as root with no jails or other sophistications. The filesystem is UFS running a usb- attached SATA hard disk. One think I'm not sure of is the present revision of the source tree. Git status doesn't report that info in terms of commit number or hash. Src was last updated earlier today. If I missed the point please indicate so. Thanks for writing, bob prohaska > > -- > === > Mark Millard > marklmi at yahoo.com From nobody Fri May 8 00:50:30 2026 X-Original-To: freebsd-current@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 4gBVsX5HQzz6cJ46 for ; Fri, 08 May 2026 00:50:40 +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 4gBVsX0RDQz3xZL for ; Fri, 08 May 2026 00:50:39 +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=1778201435; bh=/VYERan2D7C/+E0Y3I97p/16x081AAbPLrkAw4d5ioM=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From:Subject:Reply-To; b=An2srnydK0FErorBaNqMyOat416t0HrJdX7L9jPpERCihLsEbQY6VEzk5EqJLVuvuiBHiTFGy5wXgrX2i9JRfdVKS1VWTA34vvsQBKhS3d4hRhJaAcabgkhSkfi9sVt9rduLFupMInF5DTfVLyFO0Ecy6sBds3FdgIGF9YjCYndQTUFAydhB/wUDB3RGv7emTQRaH79rlVzx6w9RUq2Jz8WhWbGl0EIRU33OnMHf20kOajpihvjG2LJ0t99hhK4xMmaMgt/WVpjqmV8cXQmy6b8BxHJCn/Fqo2Z/39+N+eFm2eaGtG0nC0iGTK4mYvgGqaWjzpYTo8353jB8TYwzow== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1778201435; bh=x+LdGX8PpMMa4QXm5TyfT20M0lrj+in6H+a2ruvPl+t=; h=X-Sonic-MF:Date:Subject:To:From:From:Subject; b=FkgoikdEuuQ/sFJAsa/L4nvON+1VC0Q+1iYSLbSQVStkA9Co0QUBu93bX+L7OP6g9agJbGxNrA/MAy1fb63zktVpBRPRb42p9Vzz1e2OMHrxaVKaFswltUljVg3Ocq9Nt7Fv2EPqz72cKRmwZ1LIAONuGn1ZuJMY+XK/ITlmkm4bw5zbr0oHI8h4xp8AuUZbHJei5hjNpetGjA7+WFTb2djhpHC4q9iFuWd0JYTFfxd5Ba1WOcu7eQixNKSEu+tqgWFjY6flHqE6DdQpsjU2A4i02cgpR/ns3Sux6COCqqoPmp9cDbh7osXC4UtH0uGjn/+cdKUu4kKDsLI0pWLa8g== X-YMail-OSG: CCG0bbsVM1kZRvPvAIdI3tNMoplmLwRJvX9TXkg_Ob3r8m700Z23ZjTVRK4JRXZ TsjsiehT22SS4kM06ohZvPkmrawKBY3zlyZvhhvgrm2qEOZklfLanzkko9T5fA17967JiLavjzzm .u7O8RLJpVBubxCT.1eyMPqNE5smgNc3vQC._eawDpMrM0edlqIw4iWPDZM0mtoBSOh8hudvuX91 PiWJY8pN08QM2g3VpuXrZy6qTeNkWySBYesvpV3bXAALgCmNjNEFNaV6pL08IWbGN2SjLLnYv0BF 2vZPKZdtUNdvU4FKKsyckE1ihAHiRY0W9BAL8O2KPCENBk43NMPbbU3DJjxo.XMgYiaWjoiElLpo c1gUrAw7aNVool2CDxmhbJdA2bFfjM5VdTwDsy8d8QqaDN6lkznCIBKyovslFSWWT93xOOn7eveV xYKJYlYEBOSit6jgklSv.V7B5MOyIQm04zm55cQhP2OyUbM7S0cbA910mKFIBCsB_0Qr2v7H78Up GLZN4N6MilXABH9SOqT_bHHyC8mfN2bku24zdUu0J8f6elIGVhS7T0WNaFdh_zdzjxqUnGuBtkWr XRgtEE3ijcOiJ.Bl88Pcn9CQ_B1Ht0xH9B7XgIeqG3dcVjsvQlldnIY7O6uQYDrE9GzSw0UPqEfL ZiG2rAKrYFkw9fGICU.wty9DO3m227DIhJTJMmfHF7kjW_GnsdMqZn1E6VNxssD.OqLibjnJO.vE czPMsOW_WM_m_5orYFdcZL5xMQ.XCN8cCF7CoBXSnsdqfx6GQRbJCVYn0EaFbpBHE1atjEC20rd7 Ffo_K6YpBvHvcLS9k.kxneQ.ZtL.KmnbrUUPBmBvr6QxpIiyyw5u5M2dx4PD8.RHk1v017_bhLhO 8Latb.3i9sDwk84WD1Fg60WAVkMrtjDjHXljOrs.5LcjeyDLT.rVft3ltqGiQTuzqRUuUEXbvdfx fa2YpBl7KYj0PiM5_dqDR3qMAh48r.AvWEfij9dbV7KPWi3vdafIZQcQcbpdj.N1yl1dts4X2LhQ _hRZWzv0eUx3H01.fTHqId80b7FTpSfuNfHqTnSBD.1F2rImLbdGfsVCcvbt9hisAFpObM98138u lsZmOr8Qfp_.BHfPzJYria51UXjsnbUNaZQVW2Sf_iq5jvBg6huUYqpZgX6nwJm5YeCd90svBFVG K6dQV3MQJ9dYQx2ExRtzxajBIikhyGrkxX5a7lKVBWuOso9MTIwXcrvoSCnDsHzeKO8e85qIYoP5 Hf8r7t6fHIu8jxoWJFOcvJzIxfm96sQNx8TJxhlBUxQKluj2ulMmrrJeUbB_eW.4s7t9X5A.N8yp pecPKbTUQN_kiny_Px0gc32Shg7zU09ZO355Qczu9n2ZitRDHhkFy1g2V7755Jieyus21HeOVmbI A6adeK3hV6MQ7LWzpj6VZcQv_2Y74wXQl1aSJK9I.CHOHtLrbwpNc3iIMqHKJGomJx84jZfy9WB7 1e98.Gl4jb9ElkuaM5M_38MW.1n4ns4CNBdiso2P6xSSpDZgD3sCYJKPdLeigvdknan7YnX96mgo s1hKgjqLbfVfHpmA_PcSXrWMBJmm6rXj_GGxlcAu3yAPM2QCMgkQvIydayjbw.pYITrLjWjIXT1l jx6aaWaRfbqIDxlV5QGHDTpiLATc09FYHRXn5vxK_vr33ivOokIyQKpUk9ZLjOqoGC1NRgSDCDwf nUze89YImid4x7xwHPR44gEb0Ua1IDDwzprg2yUpdj0lwU1SdbXgvs4nwHEvgDM6A.T0L8EmuQ3e Je_OChUUAprn6ICg5LAMNRQC8H1iJ3zpMbmwcBKS7.vvMv_jcDBxTHYkEweQsNXjTu2.QaFuXbdN QGtiX5c2e83CkHt4_dstehmbQrO83o91NKEhMYYbhTzHEmC4RnSdov.W965CBeO3CnEtGJlUIgLz m7pWE88IyITHnirTFSqMWPsBiQ_ZlmU41ulCuhik5YvmnVuKkscDfDx0COy6PLtiBfaGCpjzcXUr lCDY_wDblf.jtf.dzwADFY2mt5RyQ7A0bhntG4GFRBAfpCcUrZqX5DFJfj4QeaCRzTGMT4h3_NAP jU7etiwLolmm4TZYsGXET6HkL3Uk03M1aQ14uA2ajHiZnB7U23yfhIy2APJ2U0BQb4MpEBRNN1ex UcF_uJal5VQaGrc0PWn.EAUMTu0_6fCuV0YHRwCoO7kSjFocVjSwqwyx0Hr8UHQfrV13bRk3fdi7 stKQU2azCsnbnZFJbUHoCQLb.PEag5sQoj3vciJVRQcqLqrEsPs0Qgj4k5.Dy34JvuNV.nuLW2v_ ajpBC32BoFfODJ.kUR9uR1_ankhlb5jcrOpwr3Mh9X7TX31eE8SPrn9WU_y4hhW5NzZ0- X-Sonic-MF: X-Sonic-ID: 1af1cba2-0a41-40aa-b251-d50239eed5b4 Received: from sonic.gate.mail.ne1.yahoo.com by sonic309.consmr.mail.gq1.yahoo.com with HTTP; Fri, 8 May 2026 00:50:35 +0000 Received: by hermes--production-gq1-7bb7df5c46-7wvm2 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 540dbf6d50bc0247374eda971af15cc9; Fri, 08 May 2026 00:50:31 +0000 (UTC) Message-ID: <6ae013cb-2e90-4e08-bac4-001fc8bc051c@yahoo.com> Date: Thu, 7 May 2026 17:50:30 -0700 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: ar: error: libclang.a: 'ParseDecl.o': section header table goes past EOF [So far: unable to reproduce, even based on llvm19 involvement] To: bob prohaska Cc: freebsd-current@freebsd.org, dim@freebsd.org References: <2c2ab68d-83eb-4b6d-996d-10c2169a2165@yahoo.com> <4fab914f-ff17-4312-a098-975b6c103e05@yahoo.com> <413d71d1-6e18-4c7f-8844-d85c304d0504@yahoo.com> <33436574-0b2b-4db8-a69f-85df46af12a6@yahoo.com> <7e29fc11-9fcc-4a71-97bb-b709862e35e1@yahoo.com> <9ff7855f-2b48-4cac-a82d-2cbd9912dc27@yahoo.com> Content-Language: en-US From: Mark Millard In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailer: WebService/1.1.25559 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.yahoo 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: 4gBVsX0RDQz3xZL X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated On 5/7/26 16:46, bob prohaska wrote: > On Thu, May 07, 2026 at 02:33:13PM -0700, Mark Millard wrote: >> >> How old is your environment that is using llvm19? What commit is it >> based on? > > Not sure I understand all of what you're asking. You supplied the kind of information I was looking for. The system reports > # uname -apKU > FreeBSD pelorus.zefox.org 16.0-CURRENT FreeBSD 16.0-CURRENT #37 main-n285410-c0c7d1e1af4e: Thu Apr 30 07:36:49 PDT 2026 bob@pelorus.zefox.org:/usr/obj/usr/src/arm.armv7/sys/GENERIC arm armv7 1600016 1600016 Sat, 25 Apr 2026 (UTC) git: c0c7d1e1af4e - main - split.1: grammar Maxim Konovalov Your Apr 30 PDT date is likely from the time it took to build once you started that. That is about 6 main commits before the changes for llvm21 started later that same day (Apr-25 UTC). There are no armv7 *.txz artifacts after 2026-Apr-23 18:20 until 2026-Apr-27 18:43. So I can not match c0c7d1e1af4e via using an artifact build. What I tested was the armv7 026-Apr-23 18:20 artifact build, as close (in time) of a pre-llvm21-changes armv7 artifact as is available. I do not know why the artifact builders stopped building artifacts for a time. You landed in the middle of that range. I wonder if you are seeing part of why the builders were not producing builds. But I've no evidence of that. > > Apart from setting up meta mode no intentional changes have been made. Buildworld runs > as root with no jails or other sophistications. The filesystem is UFS running a usb- > attached SATA hard disk. > > One think I'm not sure of is the present revision of the source tree. Warning: line wrapping happens below that needs to be fixed. # cat ~/fbsd-based-on-what-commit.sh #! /bin/sh git $* log --oneline --no-color -n 1 \ && env TZ=UTC git $* log --format=fuller --date=iso-local -n 1 | grep -E "^(Commit|Author:)" \ && branch="`git $* branch --show-current`" \ && echo "branch: $branch" \ && base="`git $* merge-base freebsd/$branch HEAD`" \ && git $* log --oneline --no-color $base..HEAD \ && base_date="`env TZ=UTC git $* log --format=fuller --date=iso-local --no-color $base^..$base | grep CommitDate:`" \ && echo "merge-base: $base" \ && echo "merge-base: $base_date" \ && echo "n`git $* rev-list --first-parent --count $base` (--first-parent --count for merge-base)" With that set executable, a command like: ~/fbsd-based-on-what-commit.sh -C /usr/src should help if it is a git maintained source tree. In my context for the /usr/src-alt/ that I used: # ~/fbsd-based-on-what-commit.sh -C /usr/src-alt/ 839d3266d8c6 (HEAD -> main, freebsd/main, freebsd/HEAD) uipc_shm.c: make large page allocation interruptible Author: Konstantin Belousov Commit: Konstantin Belousov CommitDate: 2026-05-01 01:06:42 +0000 branch: main merge-base: 839d3266d8c6f6471cb92a3c0ae32eb16d117427 merge-base: CommitDate: 2026-05-01 01:06:42 +0000 n285621 (--first-parent --count for merge-base > Git status > doesn't report that info in terms of commit number or hash. Src was last updated > earlier today. > > If I missed the point please indicate so. You supplied what I was after. Thanks. I'm still no closer to having an idea what else to do for investigation. So far, you have the only known example failure context. -- === Mark Millard marklmi at yahoo.com From nobody Fri May 8 06:12:21 2026 X-Original-To: freebsd-current@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 4gBf0x6TGvz6cxk7 for ; Fri, 08 May 2026 06:12:33 +0000 (UTC) (envelope-from rozhuk.im@gmail.com) Received: from mail-wm1-x32f.google.com (mail-wm1-x32f.google.com [IPv6:2a00:1450:4864:20::32f]) (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 4gBf0w1WFpz3D3N for ; Fri, 08 May 2026 06:12:32 +0000 (UTC) (envelope-from rozhuk.im@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20251104 header.b=Vhs0qK3w; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of rozhuk.im@gmail.com designates 2a00:1450:4864:20::32f as permitted sender) smtp.mailfrom=rozhuk.im@gmail.com Received: by mail-wm1-x32f.google.com with SMTP id 5b1f17b1804b1-4852a9c6309so13595465e9.0 for ; Thu, 07 May 2026 23:12:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1778220749; x=1778825549; darn=freebsd.org; h=content-transfer-encoding:mime-version:message-id:subject:cc:to :date:from:from:to:cc:subject:date:message-id:reply-to; bh=VYrDyAjfzMK/EtVxSi+3JA6IBS4EurjOtNovrV/OW8c=; b=Vhs0qK3wqby+qxJRkg9Yb65Gd1mj/eQYIeqnV+adQ4GRL2y+gajGbj20cmkQCD318Z /N1WxBtQ6GEFjJVfjyBMTLxbsnRheUIgU4j4If4QSPlRVAdppxmy83Akidms1N3FXpqX NzuFYoveWxe4ctDMGko76EaN0l8UFguMqo8ptbnybxMVxdY487nWFH8FaLXWSVuLgGam ckktxvKSIFPpURmgzTj+v8KC22pK4aCVyEDErJsztoKwmfX6xscqpjA0zCwUzR7Bxmj/ 3yQD8+/OTQJWFOLWZO/RsWCS6WEf/MN/2Knq5emlhT5ViGmOofR8P6qfaqZTMjFhsKRD NO3g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1778220749; x=1778825549; h=content-transfer-encoding:mime-version:message-id:subject:cc:to :date:from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=VYrDyAjfzMK/EtVxSi+3JA6IBS4EurjOtNovrV/OW8c=; b=jhKBQmP7a9e7/PMI3tL97fX3Ul/BCKZHTOysxg50LpTJUNCHMUw3nF0Cu7MO5Z4XRW tbXj/IbNyU07gBuOmqIBJwKqL19A0sl+uJy6xMueRAAkNgMQmQhNH33Y3voQzKFPjBU+ Al0o35cE+OZ0u6zTjQBuhYizBEDIB1zPJSh4EiXWqM2o5i+HuypwME7wfrrjARNbGTIe 0/30h/Ro91I+0SxkeczCF6u20TxRThz5u+KIcQTzziUuOXH53boSaciaXqSTCpmyWUwH G48kJzQkmfeLiH0SCBMk2JZw+gO2smDnMx5QV+aZH7zXWHC+fx0WjMORxadLbCra530x xw0Q== X-Forwarded-Encrypted: i=1; AFNElJ/Dm21RR3GRM6OungLTFgtztK65vYvj5+v7pKZYYdlO3SKXVgeI9URqBFErqgwMvsO1/rBVQP/ktjQJ+R/gdZU=@freebsd.org X-Gm-Message-State: AOJu0Ywhfojge0T+Beo4SW18GLvV4whgByE8hEmTwMJhSt4YfrLdQ3Wj UcpLp5HzECnAwjqi+vj4zE5XgU/pDRqjt0l+bBmZ8GdwwMNEly3Z8pLpMFJxUQ== X-Gm-Gg: AeBDiesY0mdenwLwgDTRep/Ip0vOGIh1CXBnX1bss4LZDCUvtN6NajuN9b8fei8Ab9X XC8QPo+bVKBwAeZ1IqtcgpzGOpfJOc+7RgdzRjRDhqs1iGolemoHLXlTLqhVrZmmQ/J5+4hwyek L5QMj1UpP2QsI38C346Hm1PtWykOlZXheh+LFP4vzmkNw26JOHGGPN2TYT9bP/biIfuhnc8UUXp m+0/4gzaBJLxwLkJfmLQ571AJWm1jORI5OteLwmW8g6f1CTsIEURAkHYfgj8Pm7aQ/xFGH0MoSS kTRtJtG5aX0xQMtNdSqtXtjmn7qRVFTg9dLg5O2PR+EcYcZqSe9JyZBPe30YMl/HTbJarhMF1Un L64yaNI7FahkV1yZ6PFsO+BuM+1BNk+376ILi5I45lL0QnONJChS5xMawq7ItD6GKEB86AswDUl CAYyglAqkCPeYaIZCAVvmAaoU= X-Received: by 2002:a05:600c:c08b:b0:489:201c:dc46 with SMTP id 5b1f17b1804b1-48e51e204b5mr128645785e9.12.1778220749356; Thu, 07 May 2026 23:12:29 -0700 (PDT) Received: from rimwks.local ([2001:470:1f1b:4dc:f026:63a:ce2c:adb]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-4548ec6c79fsm1844814f8f.15.2026.05.07.23.12.28 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 07 May 2026 23:12:28 -0700 (PDT) From: Rozhuk Ivan X-Google-Original-From: Rozhuk Ivan Date: Fri, 8 May 2026 09:12:21 +0300 To: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org Cc: Rozhuk Ivan Subject: Remount does not work, does it ok? Message-ID: <20260508091221.4a7b4147@rimwks.local> X-Mailer: Claws Mail 4.4.0 (GTK 3.24.52; amd64-portbld-freebsd15.0) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spamd-Result: default: False [-2.51 / 15.00]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-0.92)[-0.921]; NEURAL_HAM_SHORT(-0.59)[-0.585]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4864::/56:c]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20251104]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; FREEMAIL_CC(0.00)[gmail.com]; TAGGED_FROM(0.00)[]; ARC_NA(0.00)[]; TO_DN_SOME(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; FREEMAIL_FROM(0.00)[gmail.com]; DKIM_TRACE(0.00)[gmail.com:+]; FROM_HAS_DN(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::32f:from]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; TAGGED_RCPT(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; RCVD_VIA_SMTP_AUTH(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] X-Spamd-Bar: -- X-Rspamd-Queue-Id: 4gBf0w1WFpz3D3N Hi! Command sequence does not work: mkdir -p /tmp/1234567 mount -o rw -o nomtime -o pgread -o size=10m -o mode=0777 -o noexec -o nosuid -o inodes=128k -t tmpfs tmpfs /tmp/1234567 mount -u -o ro /tmp/1234567 mount: tmpfs: mount option is unknown: Operation not supported ... mount: tmpfs: mount option is unknown: Operation not supported ... mount: tmpfs: mount option is unknown: Operation not supported ... Only mount -o rw -o nomtime -o size=10m -o noexec -o nosuid -t tmpfs tmpfs /tmp/1234567 wokrs. Can it be fixed? PS: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=295096 From nobody Fri May 8 15:48:17 2026 X-Original-To: freebsd-current@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 4gBtmd2LsHz6cXkt for ; Fri, 08 May 2026 15:47:45 +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 "pelorus.zefox.org", Issuer "pelorus.zefox.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4gBtmb69jkz3DfH for ; Fri, 08 May 2026 15:47:43 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of fbsd@www.zefox.net has no SPF policy when checking 50.1.20.27) smtp.mailfrom=fbsd@www.zefox.net Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.18.1/8.18.1) with ESMTPS id 648FmI95053329 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Fri, 8 May 2026 08:48:18 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.18.1/8.18.1/Submit) id 648FmIrE053328 for freebsd-current@freebsd.org; Fri, 8 May 2026 08:48:18 -0700 (PDT) (envelope-from fbsd) Date: Fri, 8 May 2026 08:48:17 -0700 From: bob prohaska To: freebsd-current@freebsd.org Subject: Update strategy and timing Message-ID: List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spamd-Result: default: False [-0.88 / 15.00]; AUTH_NA(1.00)[]; NEURAL_HAM_MEDIUM(-0.99)[-0.992]; NEURAL_HAM_LONG(-0.95)[-0.947]; NEURAL_HAM_SHORT(-0.84)[-0.843]; MID_RHS_WWW(0.50)[]; WWW_DOT_DOMAIN(0.50)[]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US]; DMARC_NA(0.00)[zefox.net]; MIME_TRACE(0.00)[0:+]; MISSING_XM_UA(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; ARC_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; R_DKIM_NA(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; R_SPF_NA(0.00)[no SPF record] X-Spamd-Bar: / X-Rspamd-Queue-Id: 4gBtmb69jkz3DfH Is there a preferred strategy to timing updates for self-hosted FreeBSD systems? On the stable branches it's easy; just update when updates are announced and build/install. Once caught up, things can be left alone for days at least.. With -current there's essentially no pause in the stream of fresh commits, so git finds a new commit by the time buildworld finishes. Is there some marker or indicator that signals the -current tree is at least nominally consistent and buildable? I'm not asking if it'll work, just whenter it's worth a try. For example, my practice has been to run git pull, then make buildworld. If buildworld succeeds, I'll try another pull. If nothing new shows up then run install and reboot. This works with a stable branch, but with -current there are always fresh commits. I've tried looking at the commits to see if they're relevant to problems I'm seeing, rebuilding if they are and proceeding with install if they seem unrelated. Is this approach at all sound? Is there a better way? Thanks for reading! bob prohaska From nobody Fri May 8 16:37:32 2026 X-Original-To: freebsd-current@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 4gBvtD31PCz6ccgg for ; Fri, 08 May 2026 16:37:40 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from mx.catwhisker.org (mx.catwhisker.org [107.204.234.170]) (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 mx1.freebsd.org (Postfix) with ESMTPS id 4gBvtC50Mnz3Nkw for ; Fri, 08 May 2026 16:37:39 +0000 (UTC) (envelope-from david@catwhisker.org) Authentication-Results: mx1.freebsd.org; none Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.18.1/8.18.1) with ESMTP id 648GbWGv078343; Fri, 8 May 2026 16:37:32 GMT (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.18.1/8.18.1/Submit) id 648GbWVP078342; Fri, 8 May 2026 09:37:32 -0700 (PDT) (envelope-from david) Date: Fri, 8 May 2026 09:37:32 -0700 From: David Wolfskill To: bob prohaska Cc: freebsd-current@freebsd.org Subject: Re: Update strategy and timing Message-ID: Reply-To: current@freebsd.org Mail-Followup-To: current@freebsd.org, bob prohaska , freebsd-current@freebsd.org References: List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="Gxoy4Bn0ZgF48U3k" Content-Disposition: inline In-Reply-To: X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:7018, ipnet:107.192.0.0/12, country:US] X-Rspamd-Queue-Id: 4gBvtC50Mnz3Nkw X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated --Gxoy4Bn0ZgF48U3k Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, May 08, 2026 at 08:48:17AM -0700, bob prohaska wrote: > Is there a preferred strategy to timing updates > for self-hosted FreeBSD systems?=20 I am not aware of anything approaching "consensus" on that. > On the stable branches it's easy; just update when > updates are announced and build/install. Once caught > up, things can be left alone for days at least.. That does not match my perception (unless one substitutes "releng branches" for "stable branches"). > With -current there's essentially no pause in the > stream of fresh commits, so git finds a new commit > by the time buildworld finishes. Mostly, except that there are ... fluctuations in the flow ... newar significant code freezes. > Is there some marker or indicator that signals the > -current tree is at least nominally consistent and > buildable? I'm not asking if it'll work, just whenter > it's worth a try. Not that I am aware of. > ... > Is this approach at all sound? Is there a better way? Caveat: I do not claim that this is "better" (or even "plausibly doable") for others; it seems to work passably well for me. Sketched roughly (further details at https://www.catwhisker.org/~david/FreeBSD/upgrade.html): * I have a handful of machines on which I track head & stable (at the moment, stable/15; usually, whatever is jthe most recent stable release), and where I update all installed ports daily. * Each of them has a local private mirror of the 3 FreeBSD.org repositories: doc, ports, & src. * One of those machines (which is also my package-builder for the machines that I only update weekly) actually syncs its mirror with upstream as of 03:25 local time. The others sync from it 5 minutes later. * One of the laptops in question is the one I use for day-to-day work; it's the one I am using to type this message (though the mutt process is running on one of the "only weekly" machines). * Other than ports that provide kernel modules, the ports/packages are built (only) under stable, and /usr/local is the same whether a given machine is running head or stable. I will generally install misc/compat* ports as needed (and then remove them when they are no longer necessary -- e.g., after migrating from stable/14 to stable/15). * This usually works well (for me), but there is occasional ... turbulence. Sometimes, it's straightforward to address; sometimes ... not so much. * I have been doing this for a little over 2 decades; fairly diligently for the last decade or so. > Thanks for reading! >=20 > bob prohaska > ... Peace, david --=20 David H. Wolfskill david@catwhisker.org See https://www.catwhisker.org/~david/publickey.gpg for my public key. --Gxoy4Bn0ZgF48U3k Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- iNUEARYKAH0WIQRCec5RsK7Enudh3yGB9MJ9AwUELQUCaf4RTF8UgAAAAAAuAChp c3N1ZXItZnByQG5vdGF0aW9ucy5vcGVucGdwLmZpZnRoaG9yc2VtYW4ubmV0NDI3 OUNFNTFCMEFFQzQ5RUU3NjFERjIxODFGNEMyN0QwMzA1MDQyRAAKCRCB9MJ9AwUE Le8pAP4v8B62XEcC4vlwM8Xz8k7Xe+5gnOtb4W/OA3k4Qi+XwwD+N7PSbpPqDp0O bmKFKo67zeAu6cmiBNLVjpoTY/D9bgs= =G341 -----END PGP SIGNATURE----- --Gxoy4Bn0ZgF48U3k-- From nobody Fri May 8 16:37:52 2026 X-Original-To: freebsd-current@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 4gBvtZ4Qfvz6ccgp for ; Fri, 08 May 2026 16:37:58 +0000 (UTC) (envelope-from garga.bsd@gmail.com) Received: from mail-dy1-x132e.google.com (mail-dy1-x132e.google.com [IPv6:2607:f8b0:4864:20::132e]) (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 4gBvtZ1CNfz3PDt for ; Fri, 08 May 2026 16:37:58 +0000 (UTC) (envelope-from garga.bsd@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-dy1-x132e.google.com with SMTP id 5a478bee46e88-2c156c4a9efso2974243eec.1 for ; Fri, 08 May 2026 09:37:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1778258275; x=1778863075; darn=freebsd.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:to:subject:user-agent:mime-version:date :message-id:sender:from:to:cc:subject:date:message-id:reply-to; bh=bfLup602nSeas+1IebiSFdVzAfT2RcnMLV+eBPZmu8U=; b=BuWBM0KRxzqYDh+CFofbLQOW3E0q+lBBTty8prG1m2W9WF7qqt4R4dsonJ5Opr8nwi GKTcP8YiPDQHc5Z70UAnEQ1xpBiFbIB4d0qVkNPnGVWAAEQtepUWOscfxKBUGwYbXs1y N1EmaIkZsIA3fEVhKCcimVi7ub9a4TMBmaNG3YHR4t2sKDJYhfCU0X3DFzyWM40IVU3t ibZqeBhf52sV64Upb7gffTBgPS9EOwb2yKZMpo5MIIpM1+RhqI4m7emcZ9HS4Eu4rBOF EKgRJIWtL/riYrpiGmyXITS4HCXpn4MGw69y9ElEjLczIAqlO//6jnfHNxCTpYCQS0oy ewag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1778258275; x=1778863075; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:to:subject:user-agent:mime-version:date :message-id:sender:x-gm-gg:x-gm-message-state:from:to:cc:subject :date:message-id:reply-to; bh=bfLup602nSeas+1IebiSFdVzAfT2RcnMLV+eBPZmu8U=; b=g1JA7/AAFRmsU/ykh7zbOB5CW/+5cSl25I4IFYK+OyONDyD+LtTC3GTYs2nkiy5b/u d/dVqgm4ZqT8PbNWDS5WN0NP+R+C+WHyySE2uU+7VSvCWzGq+sCgOYSCH1i05DDnnvYD 0mcdmuop9jv4VWf4qOab+Qq1PYs2UlU3K1QBfsnrUOKHecU5h3VDsM//bpLUYWAk5Gwg Q+H1JE0adX6LwtAjJXauBrrrLffWgIHSgkUWjn8GKN56FacRAmrZrtCMamLBR4DSDpZm bwrqnJpX7RcTsd92ZW1A2CJgbWJ0424JDxZ681Nl9liG6Bh9G1GBVuaf3SFSyZVphwnN Dixw== X-Forwarded-Encrypted: i=1; AFNElJ82SqUkoPDG1VuIza2xAtotLM98+61wfLfme8cnm1Zk742SslDnyT6WrEuEcFBHXjNK2UOKxef2M4sisBFNh7s=@freebsd.org X-Gm-Message-State: AOJu0YxeA723PvH7fvHuNItHndpDsUjdR5lsODjgDM88KigHyp+xUkf/ sDIj9Suv7KOnXzbxKLaJ3zaCsVm5KWLdTk60x94/HOQTrM+aecMMclWd X-Gm-Gg: Acq92OG+/l6VeMnWxKKKSbNQupaANLPbZi+CD9+37lN8UAui0GvENEr2hYMwYFTvSZ2 6Kpi0saY2L/Yzv8c2cJ+ybO6lgUsxKz7v4YCBy517OwESxrN42kuAJ97wZ84kH2F19KgNo36KJE amoNMnm7s2lUijPfpCoLXe7+aF5ewfm7a21CfaZc5lwiRpBrTqFAUYcjwBWyPO4xbx9R72/7xOk Yup7BygSaJU3DFBI3sk1o4LS88K/YG+HzMq2GqvxaagRBG8wh45Tvowkgcue0d8p/a8mLLp8ra0 z3U6AD4qBNC9dPsfyLOkVUXXt3KMJSLeDtl6JyKLCQQl1VbBrUeGE6eNCh3oOCinhidryY+0a5p LRrtYXxDgN4Y4y3cXTbYfdANwCSXkn70F6CzQ4fBjGxtT6BRC8Dif5RK/TETPSeC4q0Ls66aTCX NIkehkjNJBEhfqU8GkH49KZG0Bbrgvgl2Z4bzRKGfHu3DHibYntr/OLe25iby9QJNjL25EEUQW/ igAH1WvfQjtZ1ODvAM4sx2z X-Received: by 2002:a05:693c:394c:b0:2df:71f0:e5b3 with SMTP id 5a478bee46e88-2f54f9447a6mr6347154eec.20.1778258275213; Fri, 08 May 2026 09:37:55 -0700 (PDT) Received: from [172.21.4.172] (dynamic-177-53-82-16.telecominternet.net.br. [177.53.82.16]) by smtp.gmail.com with ESMTPSA id 5a478bee46e88-2f88885be8esm2870525eec.22.2026.05.08.09.37.53 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 08 May 2026 09:37:54 -0700 (PDT) Message-ID: <9ed12219-6e78-4156-b0df-aca91a732127@FreeBSD.org> Date: Fri, 8 May 2026 13:37:52 -0300 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: Update strategy and timing To: bob prohaska , freebsd-current@freebsd.org References: Content-Language: en-US From: Renato Botelho Autocrypt: addr=garga@FreeBSD.org; keydata= xsBNBGStavwBCACjNlp/9+Y+VFe9ieR2h/WWbdvjz4Mb2z/f22bGoaskzCfvVNbo/v3i34I9 H6OdgZkGqheQEAD2jNfRbmPr4z40xDMUpYGLds+1Mvg7G3Hms3j5Ef8KaLSWUNWIfwKdfSVR Qs35ccSJxAdRW5YdI6J3xZgika+3Bc4eJ05YE/nWW+PNTYevt5rqD50N3zybVYIcLoqVPpBi AZE/sf5SLiLACIJb1t/s4x+pi8vgWevxVVT9u8V1f8zYErmHSLSqjxii0B3eRZphX9NCJOv9 +tfFZhnENInhn9gT7H4e2YumUltEy3jacONHJF3CC1pvvWEa6lEyypclMOkHQwNON7DLABEB AAHNLFJlbmF0byBCb3RlbGhvIChGcmVlQlNEKSA8Z2FyZ2FARnJlZUJTRC5vcmc+wsCXBBMB CgBBAhsDBQkFo5qABQsJCAcDBRUKCQgLBRYDAgEAAh4FAheAFiEERL7Dxegbnh7xTiQ5Ob6P xxJcZXoFAmSta78CGQEACgkQOb6PxxJcZXrYlggAgaZmr6c1yIWzN8VksHrHpwt/uxONEP+h ljy3yfrMsgfS5wx5Uzgfih1xYZUFC6jiI63CetqBqJpp3g1klRS1UWYKx2NeXphDMYZEdPm/ a6sXh4bKZbk6IE8Yn0/YiRT57d9DtbvswC7Gn7Igj/MSbhl49TvTGyvuB6juaffVoYZViomx 5zMoee8Ml2o2qj3MrCJ+/K8GU54RlpOGqGRsqdwVdr9XEWub6fF2YFwR46cjmbiU3P5urFHH nkJlBGPIwKxHimTW0lZsdx9aCKRDd/D80/WOEzXmk3k8B9lv/GsvOluHmveLhJG1R1tIJ31I f2q8dfTvqsQXnu8CcWRcgc7ATQRkrWr8AQgA1DufoxScA+CWQbUR6zExIu8wXQKrhuRt4DG2 BgynT7EMUvEBadcbQRZXsBpemNfncc9Axyut/+rWiyKJf9BLQuo/9QYmSRvW1U6+0LJUYmdg kMyBeYaPk+vnssv/u9jLuvV7FVgyE0yk1iaWIKOVDD+XrQCOvGw9uSceBrQyCyo3A/eRM/+p vnDCaywR63PKE+3axk6lfNdGK3TnaWmS30/ZDCZlNsXuqprqR4JdT5wXids5o36dsuJ5EZ20 s5hNMD34s4Yr1Y1R9elH6qBsFCpozs0+jwrArxq+UJJCR6hH5W8ZEwJtRC8tzR8mRE1WywzX BXYj0YhfGztQIxZckQARAQABwsB8BBgBCgAmFiEERL7Dxegbnh7xTiQ5Ob6PxxJcZXoFAmSt avwCGwwFCQWjmoAACgkQOb6PxxJcZXr1vgf/SKXhoZcUU5I7TqcbHg0lJz9tICTupCGHWr/s SQgjh9oEM5j1wqW7FlCGP90Tl9K0g3ow9YdbhU7VK470o6pymX9V9eLHzGgkZO/KMEtGBeK1 u+5ePjCJ/MK5B21KODLSU7WrIL1VN5ceXfQPLYt02LMLtPri+oduHD6RNBeA7US1DUzleq5F 9NHGbvV2U7BdDUezpiO8NaFjFZVB11I5d99FxUM5XGVstI3VhsRKZxjY0KnqJzaQgTFsPGmv AUfZVIN1pXgXiedhPXpr8+Y64jP+pHVwpVmh1zYWL6+q3kqFOUVP6c5iiMeoEXZvgJz7x/AC ek3X5gvu8Hpcv+MZIg== In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; TAGGED_FROM(0.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] X-Rspamd-Queue-Id: 4gBvtZ1CNfz3PDt X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated On 08/05/26 12:48, bob prohaska wrote: > Is there a preferred strategy to timing updates > for self-hosted FreeBSD systems? > > On the stable branches it's easy; just update when > updates are announced and build/install. Once caught > up, things can be left alone for days at least.. > > With -current there's essentially no pause in the > stream of fresh commits, so git finds a new commit > by the time buildworld finishes. > > Is there some marker or indicator that signals the > -current tree is at least nominally consistent and > buildable? I'm not asking if it'll work, just whenter > it's worth a try. > > For example, my practice has been to run git pull, > then make buildworld. If buildworld succeeds, I'll > try another pull. If nothing new shows up then run > install and reboot. This works with a stable branch, > but with -current there are always fresh commits. > > I've tried looking at the commits to see if they're > relevant to problems I'm seeing, rebuilding if they > are and proceeding with install if they seem unrelated. > > Is this approach at all sound? Is there a better way? You can follow the stabilization week mark. More information at: https://wiki.freebsd.org/StabWeeks -- Renato Botelho From nobody Fri May 8 20:10:30 2026 X-Original-To: freebsd-current@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 4gC0c92P2Zz6cv8x for ; Fri, 08 May 2026 20:10:49 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: from mail-pg1-x530.google.com (mail-pg1-x530.google.com [IPv6:2607:f8b0:4864:20::530]) (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 4gC0c9090Vz3pjf for ; Fri, 08 May 2026 20:10:49 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-pg1-x530.google.com with SMTP id 41be03b00d2f7-c801b30188dso1091837a12.3 for ; Fri, 08 May 2026 13:10:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1778271042; x=1778875842; darn=freebsd.org; h=to:references:message-id:cc:date:in-reply-to:from:subject :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=r5XumCqdxY0MqhEDPV39cNOx1av2YYydrh+KsuqT6V0=; b=kISxe/813JkxbvAchtgG6ZwlxPcxU+8EKPvDkILIctvEH6sEs199DLMHdo2M3kas+x 0uN48jdIIpU5qvn+xGwEse0KNWxzN+WACDSH8gYxPuesIVykuQMUn89YyLio8QTQalAX LXFHW5kmu1SJAlLuPGgJxXXjmQi9SLKXTpvAB/egp34ngyDqtj4zr1K1FhxfF8qNAcqe Y7OUY80uLnmb1q6OGXUGN5jpfcpxKTVzzCio4kn1f4a0lebvzZczzI+0Nsv/kSJsawVn cyTUBLXM3nHx5z0BleGBYQBqv/mBnYZkNGt3eXfi17lWiEAUfCUsiLTdZPa9paQZIBsV /9NA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1778271042; x=1778875842; h=to:references:message-id:cc:date:in-reply-to:from:subject :mime-version:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=r5XumCqdxY0MqhEDPV39cNOx1av2YYydrh+KsuqT6V0=; b=NWOdbb3oJAwfiQaYeRNltkLO5x4gYO75BK56BTBnyqUv7JljPNcZGKPEHuO/iY1OzP Ylcklu6DTngbMMqisvq55KK/i3W37K6X91poFTmHVUXlWWzf4an9y9FHQqvJdLjNipox tlasIBxOPUkMx4M1mFZjZ11nBmFkCKL4QO71QdlaMxe0vlsKctCliDi2ixm7UtcW9+F4 6rjBFEcNI61nKZPHqB7wWRb6R5Z91ECCfdWY4lLqiqV3BgB4MBeKUxRdxXAdxH1EICYQ Ou/dpW9s4ZtcYpHczknj7nsS8l12B6XCFJoVM0IBsg3sfkq/7lfk22yAhQdcSesqTCT2 MDeg== X-Forwarded-Encrypted: i=1; AFNElJ8XitUvUlVMYwS7yr5Au49yW8C9kOVicsYkQvehgAxyxmKMPSinxfUvur26FtepV8zc86qfXLpSU2U0pqK1SHk=@freebsd.org X-Gm-Message-State: AOJu0Yyl84XT8sMnkPjsoKrdcuh0u9+BvIBHLhhPaU+tMk/5mprybBHG r/bJPKZSN8HyYcmLufIZwbIZnTvD/KNgq9diZE0/KAOC/+/BakyNhl+kLdJ1hs3n X-Gm-Gg: AeBDietq+TO9qKtwrhfSK0Iz49k1qE8Tda7yCrPztikwFhWHepOrP/vEnpeMCUKTHX8 CVB7yugfn8+vqANwaJCHmdCuHr7VUKdJ29UkOC/HCiCUeWZcAwYeZMN168UzzbWNRv0GPtGjgoE JI1X4Ygt9hH6Ozd79eWPSP3XwilA9C3Hakpq3ck1Kj8Vpo+k/TVpnKPE3FUK8IZOD6r5ZsBif13 BrF8OyoBaN9o4xx51kjk/W7GVq2rWhJPjQBB+0J4QVHpa1ouVlKBvf2M/A6kwBbJJBA5RjSOEgq 8Fw+qZNyIqKM3u9B5mFQX6T8BQGyXDOWTBlHJmMiD1nAqEYxLcNx3MK/31GwRqHbPLPkVmaQ+AQ 9CpaHM4hsM9k5hTXCENcWBsYbMbVj7U5Ro8IBxqzd9Zh+WTla3feg6r5ZFC2mPr9lvmITR/+Cr+ CcdpFc5M3RH3K8R4LpW9hdqxLbNjCRVSJL0fEzicEDzWekxqYH X-Received: by 2002:a05:6a20:734c:b0:39b:cb47:7008 with SMTP id adf61e73a8af0-3aa5ac4f9c5mr15078589637.53.1778271042461; Fri, 08 May 2026 13:10:42 -0700 (PDT) Received: from smtpclient.apple ([185.153.179.245]) by smtp.gmail.com with ESMTPSA id 41be03b00d2f7-c8267735e3fsm2571643a12.31.2026.05.08.13.10.41 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 08 May 2026 13:10:41 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_9A2AE967-3B7F-4750-B278-BD93AA20B4DD"; protocol="application/pgp-signature"; micalg=pgp-sha256 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3864.400.21\)) Subject: Re: Update strategy and timing From: "Enji Cooper (yaneurabeya)" In-Reply-To: <9ed12219-6e78-4156-b0df-aca91a732127@FreeBSD.org> Date: Fri, 8 May 2026 13:10:30 -0700 Cc: bob prohaska , freebsd-current@freebsd.org Message-Id: References: <9ed12219-6e78-4156-b0df-aca91a732127@FreeBSD.org> To: Renato Botelho X-Mailer: Apple Mail (2.3864.400.21) X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] X-Rspamd-Queue-Id: 4gC0c9090Vz3pjf X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated --Apple-Mail=_9A2AE967-3B7F-4750-B278-BD93AA20B4DD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On May 8, 2026, at 9:37=E2=80=AFAM, Renato Botelho = wrote: >=20 > On 08/05/26 12:48, bob prohaska wrote: >> Is there a preferred strategy to timing updates >> for self-hosted FreeBSD systems? >> On the stable branches it's easy; just update when >> updates are announced and build/install. Once caught >> up, things can be left alone for days at least.. >> With -current there's essentially no pause in the >> stream of fresh commits, so git finds a new commit >> by the time buildworld finishes. >> Is there some marker or indicator that signals the >> -current tree is at least nominally consistent and >> buildable? I'm not asking if it'll work, just whenter >> it's worth a try. >> For example, my practice has been to run git pull, >> then make buildworld. If buildworld succeeds, I'll >> try another pull. If nothing new shows up then run >> install and reboot. This works with a stable branch, >> but with -current there are always fresh commits. >> I've tried looking at the commits to see if they're >> relevant to problems I'm seeing, rebuilding if they >> are and proceeding with install if they seem unrelated. >> Is this approach at all sound? Is there a better way? > You can follow the stabilization week mark. More information at: >=20 > https://wiki.freebsd.org/StabWeeks +1 to what garga@ said. Generally following the =E2=80=9Cpost-stab= week point=E2=80=9D is the best way to handle things if you don=E2=80=99t= have the cycles to debug/triage new issues. If you have any suggestions for missing tests to make your = upgrade experience smoother, please discuss them in a new thread. We can = get the proposals entered into Bugzilla and hopefully handled in a = timely fashion (if the scenarios you=E2=80=99re requesting are easy = enough to implement and make sense to cover in a universal manner). Cheers, -Enji= --Apple-Mail=_9A2AE967-3B7F-4750-B278-BD93AA20B4DD Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEkHfexGRJ3gYRdA2gGpE5DjPsNJgFAmn+QzYACgkQGpE5DjPs NJgZmhAApcK+pUo50Q671Eimn3hTy5vjBzEoDq2HxFCMOr3yICzfBhvntEX3eilT tsUUK1lnwiMldWmKLC2P7FSfqiYXR4sIFI6L5t0YM93Nq2qMgeMtW5ML1+RSiIpo BpM55+kDgtiSPpJIkkvqx2SotrOB+NFmG7+nNcKwvbrGL2yb+3wSk6wkONCNQG6f raVULarny6FBYittRJ7UdfEs4PgP4axh1n2K25lkHUVfLbk1QSDXYpUZ6+zysr1h 4U5KW9WnqONBp0WGj0dVflNIbwTuaTYqdy4UXHnrL7P0nLYCTJ3gguRwpLVWWWpf JlJR7ai6Lwlioci7069hsBOy2JLHuZQMl3gB9knu7AvZPltsuRVuuXoe2+lu/1vz FyznX3uLhqd6kiFYjPOxTyVkUUxW/X8VXOvUiu57o5gpy2p/Nh4potcjz1AI3Rqm QhuIRILAincEq1+UsEsbEZAnzYC0d7By/t/ookiY/Lo5jCXhrMzE1isJkkgOY2R0 itGOtPghcOTNA6YHUG8QUyek2lMuVeV1x35G3q2TQ64VvAEWzAg2T9FiQHjavz2m dhf8rOFR3/UmjIQo99xDaaf7vULQQQy7FcDpOlpA6rlCJd0EKroqOw9aX2ElsR9f sh96tIzsxehxAN85nxpPCH7d7kA7ZMnTOa/NAnPKogAkKTQax/Y= =UQ15 -----END PGP SIGNATURE----- --Apple-Mail=_9A2AE967-3B7F-4750-B278-BD93AA20B4DD-- From nobody Fri May 8 20:29:50 2026 X-Original-To: freebsd-current@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 4gC12M3VKgz6cw4y for ; Fri, 08 May 2026 20:30:03 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic308-55.consmr.mail.gq1.yahoo.com (sonic308-55.consmr.mail.gq1.yahoo.com [98.137.68.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 4gC12M18N2z3rdb for ; Fri, 08 May 2026 20:30:03 +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=1778272196; bh=7QAJJf/DsVe/osZYWTTL6cZ/PeuXjjz6oGTpU2hHT0E=; h=Date:Subject:To:References:Cc:From:In-Reply-To:From:Subject:Reply-To; b=IZNQHaNND6EzfL3gnG8jrP5uv1uMGmSsqb0kUAfBZEMzNpMoZl5flsrwuDouAfoQ5OmaASCbSIw6E+ZfAusgDMQTPBpYwEcoX5kIorvc7a9lHaFeasawCSjwymSPWUm1GTdg7k0tlb326wDB87dAStsGSkMv665lgQzSPyGOzON2ws3wiURUYcNgxiwOcHbyjx4OHbkMsOGm5O1n1rW+0VXQiD7NifJ3IKMHF5/GMKuuEYj8FdZx7/LOV+V1nkrR87GQ7CYM/isMtggSUJM+VavTWE4Fel7UBkhEplKgGsN/eET0vSmupWvTfh9L5J+BAkNCiO/gaIVSR6gj/PTcvg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1778272196; bh=2iIGeFGZ9T/QfzHrxLAIytbGa4TV6yO5tiHfL+nbdn+=; h=X-Sonic-MF:Date:Subject:To:From:From:Subject; b=fBxr/scoT4aZKbhc2n6sDZWvfn5WfsJc/YDX3DOjx5GgyxTYoYbR3PMe+k03P4rLAHyRlVT2JXVEX04T3axbiiuZ5Ki8zIRbm5i3qpYNL84n+fDLHl0XY8d9Ko/vFXF4nwkrdiefgvVurbxMKUOUJ+juq6DP6K22V1Ph+vQXe71sRH9NjesC96LERhTk7pi1KNGG6TGND0kqnBFNa/8C9bbhkc16aHtw1pwYH+KqH/YolkqcFcgN+P1tUzt+8zcMLXy1JRAeNDR3XXeKagNG8uB3184jF0AAyWgBDBeKc7MyDB/fdkXVWQBdIMyUk1T246DAkTemNf/6kx2yhjyiUw== X-YMail-OSG: JMCkSuEVM1m0P8njTCL1BwwBq9YNQLVHxSBo14qYWkPQ7lI5EwyS3hrG2V4o4pi hkYArCK_eRfWGrY_tnVUofCPIXcG9SaDuYeApp8BkiIibk16vDFxCaSaxwEfwDLk2Lno5evvPX71 JiVrSdPBTg7e_cWAJFLga8vpNtAeh9UNDuNngxLV8pyr2nrZ0VlmT.GuGMxhnTcrEz5aRlkXbK_8 PaaXX7msw44Jg2L1d_cnWUiR01WSXYF93zBgTLvUyMcmoDGJntxHvPpG1mVuyqwcf.K8minPCjam Tlx8sTpmQvS_85_01vHdOH.WShUN8ChtX9jGMljSqG9iR4VZJUVQZROPAHJ0bLTdG9ImZS6OaAZq g933bziynqmeQ_Jq3Gcet5o_VmupdDbD6Kps6eYRB0n86_8qOxyXcQjr3i3ih3h.Cl8d8f4T0OW6 UwjylQ.zz3Pbxi9C5MwcBZSfaWWFYAu4trzn9o7bB5YtZ3RTqlu.IEefKmge4wIMMhc.TfFiDtkk Z9qVccb2304lj85rnqAKN9OeWxEJ18f2tDB6DflilGL3VptYXYralR0LSOYTJNgdWd7vFXdDvvhl hq_ipOOTMmgU38jCwcZomrhx_z7sdCg9mGwM.88gbbcz28RcRGU80pxK_ebsBEC2qYIAYxEV42Ai uhPWKsUhZ3c.zimVAuMY7i858Q1OvtIu6Ycu1yhp.cDTGMXqANxJmJcc1YAY8aflBybRdPqnaL6U CGsdMGDhvsEzt85jiafu9o9l8Kwk6FcF824UbTbtxCTne.gi3rxWyxgamQEO8JsVTyMKPg4TISJy IWu.gWRT8Xo3SMrZzd.5CyjqFocVuVX2gqXvvv9seBBPh.PBl3Oie5wEHGrRq6u5hZXSyG9_hMKX S8ifKttytsB2HT8kj917vhh5In2JWRlz3W65RpJqlKaJ.t1jraHUxqvo_aCSf15Z7aQ4iVAq8wRI kpxtJAdqomsfsxywXPhJyHKjP0TvY9Fp9tG_NZMDzsrp8SE8YSYkti4jLYCX4PhUNW...KMwM..Y 3oYo09atHUAtHh5DkQMMRbiMrhJSgXD4vtcCcLFoGx4IuuxGajT0Rn16tMogthJo1z75x3GPKpTK mSq3thkAvBHeia2ZrLr0a88ZKIjvP8fDQDKLrRQf4.UlbOeZqeMOuZVM7wOcTWyF5hocf7MtOQAl J6h7tpY.v.T0.EGfqzF5KHe7JqSPb4Pj41ctSF7qB7Gc8M.NWPAmq7RqkA3mMb.aY2Bp59yEm9H4 dI7itMZ3iLCaGZ2OfklimnHKg5t_IUxWsmA327XcfbV7VLkRrnT.m3wgQA6G8NdQna4dYoFOSZey grGKY4BnO2sOJ4yfX4D0S8PzFJeVibtUlzy7yAq3m0incIYXlv0c5QQcMyn9wXmEcb0S8xwnc2mV GSU4pVhHdIblagHsnPI7VX0R3Qqovi7CzcW2M0B0hJ5vkrS4hSQWYedS8zTQnawd_6De2NHJnpvx xbaSzlRVsrE_SXBlL0q1zv2nda5n3m1ZwqbelZ3aj2D7kvSkL0.PxdKQ07rbnjwKfHYsp4fjMwKH oo4E6y.Qa6bNsanZqgmSJVVTpiCSjOK1d5TYrXw79TijdTNUpA79MK17K6PRBChCB07uKfmrpsX. rFCBZjb9MdwsY5JO1Dcv_F3_ie2WBmVkO4zsJ9v8aS8x4QwGy2twdmxTJ2Oz6.WqyWBVjPZ7lE6a 36EKNjnLdBzMCTgD.P0rOCfzSWlG3woRuiOL8xH25sp0jZogqzyvFH4Fxfm52Qe8o36ujGYJiicR L.ZHqveUy_UQxD_XQkdZYMk9Qmi_dADbgaEHV9hn5RSo531FEjGRvVyO3zOc25Z6mmssobHZD7W1 Wkpk1g3mCApNOeCL8EsrRXvr4zVb_rzWVBdmcCzcVSCRZLbhmtVzg3RGwTHQP52WqVzYdxVQFq_l wiuY_QEXWF0zYyFtN0UUgWRop1rtESy05cMHX3jU8Q5mZ6teJol8zEtKfqni5obSVOe6QjhayhVw R2SVpdkcPzL3FRlG9FWTZbeNw5NBefARFnSzD1O2mLw64iJi2wtOn_ZRtYHE6NjXWPp1BCkms65R 0wqP0izEF9kqPYi2MP8EkqATV17iMyYy4FQVY5nARpNU1PUHUOmooUcN_RNBiYNEPdMY0YYaIkYO 3RxuAZFSQ2tkC288s6IV6cZLHabWBhYGBLWZjUbaID0iDw4FhiqMrHT8szZ1SW3G9AL16bSqgc6O ldtO1GvQ9PqR50e0r7ituY0wIVnLSCXDpn9R4kZ6OD7ckPitXXYp35LSmS0QTDO5s1eOdIKojnMm WSFbqG9_KgXJUGVVKcrAngPrw8yjEv3ZGu_jwZEq5tssAIW.BqxkLOA1EDw-- X-Sonic-MF: X-Sonic-ID: 54a5f445-8616-4a42-8cda-2dd648af52e6 Received: from sonic.gate.mail.ne1.yahoo.com by sonic308.consmr.mail.gq1.yahoo.com with HTTP; Fri, 8 May 2026 20:29:56 +0000 Received: by hermes--production-gq1-7bb7df5c46-cpn2t (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 144fc29d602d1eda3b5a91d0b5cf2ef3; Fri, 08 May 2026 20:29:51 +0000 (UTC) Message-ID: Date: Fri, 8 May 2026 13:29:50 -0700 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: Update strategy and timing To: bob prohaska , freebsd-current@freebsd.org References: <9ed12219-6e78-4156-b0df-aca91a732127@FreeBSD.org> Content-Language: en-US Cc: Renato Botelho From: Mark Millard In-Reply-To: <9ed12219-6e78-4156-b0df-aca91a732127@FreeBSD.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Mailer: WebService/1.1.25725 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.yahoo 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: 4gC12M18N2z3rdb X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated On 5/8/26 09:37, Renato Botelho wrote: > On 08/05/26 12:48, bob prohaska wrote: >> Is there a preferred strategy to timing updates >> for self-hosted FreeBSD systems? >> >> On the stable branches it's easy; just update when >> updates are announced and build/install. Once caught >> up, things can be left alone for days at least.. >> >> With -current there's essentially no pause in the >> stream of fresh commits, so git finds a new commit >> by the time buildworld finishes. >> >> Is there some marker or indicator that signals the >> -current tree is at least nominally consistent and >> buildable? I'm not asking if it'll work, just whenter >> it's worth a try. >> >> For example, my practice has been to run git pull, >> then make buildworld. If buildworld succeeds, I'll >> try another pull. If nothing new shows up then run >> install and reboot. This works with a stable branch, >> but with -current there are always fresh commits. >> >> I've tried looking at the commits to see if they're >> relevant to problems I'm seeing, rebuilding if they >> are and proceeding with install if they seem unrelated. >> >> Is this approach at all sound? Is there a better way? > You can follow the stabilization week mark.  More information at: > > https://wiki.freebsd.org/StabWeeks > Note how this example would work by you [Bob P.] choosing to use somewhat older vintages that have been separately tested --based on the test results indicating evidence of some stability for your workload. That is instead of using the most recent commit that have not had later, separate testing. The details of the specific testing seem unlikely to be biased to issues more specific to armv7 on RPi2 v1.1's or aarch64 on RPi4's, RPi3's, and RPi2 v1.2's. I've no clue how the testing would fit with your networking context. The testing is generally monthly. (2024-Dec was canceled, for example.) "* Last week of a month is declared a stabilization week . . . For our purposes we will use the week that contains the last Friday of the month." Also: "Monday 8:00 GMT a tag is created and published. Right now it is published at [the glebius] personal https://github.com/glebius/FreeBSD/tags. Note that the tag points at a hash in the official repo, so there is no trust involved here." More from: QUOTE of what glebius wrote: At the end of the stabilization period be it Friday or earlier I will write email to current@ reporting the results: - were there any regression identified with the Monday tag - what has been accumulated in the stabweek branch - known stable point(s) of FreeBSD/main during the period, recommended for use The free riders who did not participate in the testing are now welcome to update their machines to published stable points :) More seriously speaking, I actually hope that in some future snapshots.FreeBSD.org will start using these points for snapshot generation. END QUOTE As far as I can tell, use of stable points when fix hashes are involved means git branching at the (final) Start hash and then cherry picking the fix hashes for the Start hash into that temporary(?) branch: the result is not at some commit that is directly on main. (main could have had other changes mixed in that were not tested.) So it is biased to folks that use git somewhat more like a developer. Sometimes there is a "use hash" from main instead of cherry picking. The freebsd-current message closing the stabilization week is essential to giving context about what to do. I do not know how this fits with what you are comfortable doing. -- === Mark Millard marklmi at yahoo.com From nobody Sat May 9 15:57:45 2026 X-Original-To: freebsd-current@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 4gCVx80xm6z6c5Wj for ; Sat, 09 May 2026 15:57:16 +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 "pelorus.zefox.org", Issuer "pelorus.zefox.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4gCVx73T6sz3s6L; Sat, 09 May 2026 15:57:15 +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.18.1/8.18.1) with ESMTPS id 649FvjV8026558 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Sat, 9 May 2026 08:57:46 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.18.1/8.18.1/Submit) id 649FvjFq026557; Sat, 9 May 2026 08:57:45 -0700 (PDT) (envelope-from fbsd) Date: Sat, 9 May 2026 08:57:45 -0700 From: bob prohaska To: Mark Millard Cc: freebsd-current@freebsd.org, Renato Botelho Subject: Re: Update strategy and timing Message-ID: References: <9ed12219-6e78-4156-b0df-aca91a732127@FreeBSD.org> List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: 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: 4gCVx73T6sz3s6L X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated On Fri, May 08, 2026 at 01:29:50PM -0700, Mark Millard wrote: > On 5/8/26 09:37, Renato Botelho wrote: > > On 08/05/26 12:48, bob prohaska wrote: > >> Is there a preferred strategy to timing updates > >> for self-hosted FreeBSD systems? > >> > >> On the stable branches it's easy; just update when > >> updates are announced and build/install. Once caught > >> up, things can be left alone for days at least.. > >> > >> With -current there's essentially no pause in the > >> stream of fresh commits, so git finds a new commit > >> by the time buildworld finishes. > >> > >> Is there some marker or indicator that signals the > >> -current tree is at least nominally consistent and > >> buildable? I'm not asking if it'll work, just whenter > >> it's worth a try. > >> > >> For example, my practice has been to run git pull, > >> then make buildworld. If buildworld succeeds, I'll > >> try another pull. If nothing new shows up then run > >> install and reboot. This works with a stable branch, > >> but with -current there are always fresh commits. > >> > >> I've tried looking at the commits to see if they're > >> relevant to problems I'm seeing, rebuilding if they > >> are and proceeding with install if they seem unrelated. > >> > >> Is this approach at all sound? Is there a better way? > > You can follow the stabilization week mark.  More information at: > > > > https://wiki.freebsd.org/StabWeeks > > > > > Note how this example would work by you [Bob P.] choosing to use > somewhat older vintages that have been separately tested --based on the > test results indicating evidence of some stability for your workload. > That is instead of using the most recent commit that have not had later, > separate testing. > > The details of the specific testing seem unlikely to be biased to issues > more specific to armv7 on RPi2 v1.1's or aarch64 on RPi4's, RPi3's, and > RPi2 v1.2's. I've no clue how the testing would fit with your networking > context. > > The testing is generally monthly. (2024-Dec was canceled, for example.) > > "* Last week of a month is declared a stabilization week . . . For our > purposes we will use the week that contains the last Friday of > the month." Also: "Monday 8:00 GMT a tag is created and published. > Right now it is published at [the glebius] personal > https://github.com/glebius/FreeBSD/tags. Note that the tag points at a > hash in the official repo, so there is no trust involved here." > > More from: > > > > QUOTE of what glebius wrote: > At the end of the stabilization period be it Friday or earlier I will > write email to current@ reporting the results: > > - were there any regression identified with the Monday tag > - what has been accumulated in the stabweek branch > - known stable point(s) of FreeBSD/main during the period, recommended > for use > > The free riders who did not participate in the testing are now welcome > to update their machines to published stable points :) More seriously > speaking, I actually hope that in some future snapshots.FreeBSD.org will > start using these points for snapshot generation. > END QUOTE > > > As far as I can tell, use of stable points when fix hashes are involved > means git branching at the (final) Start hash and then cherry picking > the fix hashes for the Start hash into that temporary(?) branch: the > result is not at some commit that is directly on main. (main could have > had other changes mixed in that were not tested.) So it is biased to > folks that use git somewhat more like a developer. Sometimes there is a > "use hash" from main instead of cherry picking. > > The freebsd-current message closing the stabilization week is essential > to giving context about what to do. > > > I do not know how this fits with what you are comfortable doing. > I think it's sensible to make a point of pulling and trying to compile the source tree at the revision identified as "stable". It's slowly dawning on me that there are (at least) two different aspects to my question. The intended goal was to find out how to avoid attempting to compile in the middle of a commit process, where some files are updated but others not, yet. It's unclear over what span of time a commit, or set of commits amounting to a fix, takes. If seconds, it's a non-issue. If a day, something worth avoiding if possible. Another aspect is avoiding trying to compile sources that are complete as intended by the developers but which may not run correctly even if they compile and install. This, more ambitious goal, seems to be the point of stableweek. Broadly speaking, I'd like to avoid build errors if possible so that test builds have a chance to crash. Up to now I've guessed build-time errors are of the first type. It's my assumption that buildworld is hardware-agnostic: Sources can be expected to compile without errors regardless of hardware target. Whether the resulting binaries actually run as intended on the target hardware is an independent question. Is this notion incorrect? Thanks to all for reading and trying to enlighten me! bob prohaska From nobody Sat May 9 16:07:47 2026 X-Original-To: freebsd-current@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 4gCW9h00Wjz6c6rC for ; Sat, 09 May 2026 16:08:08 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Received: from mail-ed1-x52e.google.com (mail-ed1-x52e.google.com [IPv6:2a00:1450:4864:20::52e]) (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 4gCW9g4h2nz45Br for ; Sat, 09 May 2026 16:08:07 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ed1-x52e.google.com with SMTP id 4fb4d7f45d1cf-6763cc8775cso7204884a12.0 for ; Sat, 09 May 2026 09:08:07 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1778342881; cv=none; d=google.com; s=arc-20240605; b=JbVOiOl9nZlrNvS/B6Zkxi+RrwzqHvRf9VKNTU0a6fYJfn6verX/BTCU5D3RnkPRtS DwTzhvNNGU1j92CMuqNcvull49dOKxli9mJAxOAM7Sg1jZ+RYxfiU82DiZZa4SX06bEO +zLTz2O+Cs7g+f1KQy5Sn4GCn89bh2Xo2fZLGTeR/FWKOfiidJySquAoWsaR/k6bWX5t 9tbeASUYCsegkzXjoYZRJJw36Qa2uv8miVniCh9fQgfTXatixslQ9z5cM49/ZXG/z1Lf lqzgMUwEEzRDt3k9ZloMDujw9eEDAocftpF0DoVes11AufpLYZwkSaQLW/Skcq1zYNNi fdwA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=UN+I5YwiZ34PjMo78/dnsOojZtwKaqEl1LSdlUiGKW0=; fh=S+vnx0N5MiLYknt1zXSKHJXZbLGyGrWeyNrtNGuvMbo=; b=BbyDjFEUUbjFnvAbh488vDSeRRch3qsIZ2F3cqYHchtcCjwiHhgmuWC3grwgawSDAQ JMO0mMeZnT3tTGUOM9D6zyZz9NX/4J4fJRoD02P240oZf6yzPh/Wg681KWknzzyNSOQ0 IVVvStMhoiy5qEAgwVuK3rqCHVVJwGO07gdGX5jUAwaEFd283AbMrshFdg8zuPFHEGhd Xoz6lEvsB9n3jmYamdZ1x+Ld/VLiY9aSGtuaWCn/45JdM+KgyQVtZxoa1u2mU93iwj3x JJU2hHeZE/s3uw6pspEAMcBMp2EAWNQiX7ZojpyQ/abj9HZXL1EjT7f1n93nixg2l0zY mjJw==; darn=freebsd.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1778342881; x=1778947681; darn=freebsd.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=UN+I5YwiZ34PjMo78/dnsOojZtwKaqEl1LSdlUiGKW0=; b=awm/AnVgqlQTHjJrKvwwctt6tR8GKMBJaSFJtvUAOtnxElzzUcBW8NGwsa30JLqGYU PezfEMY9/M7sCWysvh8zOMY9xpdt4pZcpsa1NgEtCcnXfJLrpfJ5z1WvzqqHOmVK1DMy cHEe4h1qNZb11hlSxxcziB7ehMXvqTMdJxQ0iEhjO1AKAYmy0L81AFWhFhtvb3fITRVx TNIrfzp+IZpWgeFZ4/6yDd5v+FeRMvFFgOGtoqrNeTeV/qTu0r9/KrS9fgT/r5BmNDDm o8S7K6FuUOh4sL/ZzsTRLu0Z0hbfLNJbupVSiPWXR+m57AX7tj0taF5BITJIn0imm6aR +dVQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1778342881; x=1778947681; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=UN+I5YwiZ34PjMo78/dnsOojZtwKaqEl1LSdlUiGKW0=; b=gRKpuliUYclBuhZ9Yl6p1QvIWx2Ase4TBoQEanfwrrdf3JEkNNiv+OJoq0vyIFn9HK bI+jJYZY3rbsexkT8YA6LwNlIa7bNUp86AueCrlAG/lvKfptsX77eOzHfTmjKsxHUj32 4CG9f0Dia0Y+s3msWwbQPPz+mQQt4zseGuXNfoH51heLla2Mvyuqkm+QmohyICqrvKqp ql5ecXwKAHBN7P1YaHkZwh/sIHZxYeVbZgojxzN96YKZr87I0EVMk1JqRLvhIjTmLFoj to/CapUWc+vZWyYqHp5Cn0jkNpjpV5uMGrW5E7XtbWAXexKsIsd68Bj434aHQPq7WfVC IHWA== X-Forwarded-Encrypted: i=1; AFNElJ/hfBQjWkV4UVj8Z6Tm47ZbPOlevLeuUt2Xc75rn/6yKNR2KuMzcS+/FQlV+FK8BjLpgV/K5zzSzYrt/+PVo50=@freebsd.org X-Gm-Message-State: AOJu0Yw07zX64zv04LfZ56aeNzjxIL2w9o2SXdzbJrf2ePH+HYzgO4XJ 99AxBhuaCb5wlIrIas9Efpg/NisYA+0l6tVR7pS1MkIrP6gjw0VIUOIvQhuv45WTfbDHnas/VF3 OOtbfs3ztVsGYtb6pOGzJnrQn3aemEQ== X-Gm-Gg: Acq92OGYVkDS/se17ruS5gNLzFEltAEVE6i1il2fcofM06cSB402g0CO19/jQ2GRBCR j0F28w2pPG/VhzyEI3gyFcqTpDT1VOWuoe7UK+dRd6lAw0Sfs6l0D8Rasm+HsD21NUSU/j5u7fL b6uUnKaAsdgOgdcioeaz90Tnzve7DDQmoVnhBhf4C6XeYh9IGXEKag/fTlYdxZdJuuKnR8VXZkK z7qLJSfB4CTyh5ER1yrKyTrNGZ3iJJv+tvpROZGtKfUUW5EtkWsKY/v5WKWwd8DW5OjHiMZiZBG 1d5c8LhXKIbCc6K4C7WGGbQLe67rg/uKzdUczE3PR7aK7m9boA== X-Received: by 2002:a05:6402:b8a:b0:671:9dec:ba3 with SMTP id 4fb4d7f45d1cf-67e0ee9abb2mr3634644a12.13.1778342880263; Sat, 09 May 2026 09:08:00 -0700 (PDT) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 References: <9ed12219-6e78-4156-b0df-aca91a732127@FreeBSD.org> In-Reply-To: From: Rick Macklem Date: Sat, 9 May 2026 09:07:47 -0700 X-Gm-Features: AVHnY4Ifygw5nxKqPACZz2yefXuSdQEWOg_xwXnY9fEkC1_ULknPhojTbzPF6dg Message-ID: Subject: Re: Update strategy and timing To: bob prohaska Cc: Mark Millard , freebsd-current@freebsd.org, Renato Botelho Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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: 4gCW9g4h2nz45Br X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated On Sat, May 9, 2026 at 8:57=E2=80=AFAM bob prohaska wr= ote: > > On Fri, May 08, 2026 at 01:29:50PM -0700, Mark Millard wrote: > > On 5/8/26 09:37, Renato Botelho wrote: > > > On 08/05/26 12:48, bob prohaska wrote: > > >> Is there a preferred strategy to timing updates > > >> for self-hosted FreeBSD systems? > > >> > > >> On the stable branches it's easy; just update when > > >> updates are announced and build/install. Once caught > > >> up, things can be left alone for days at least.. > > >> > > >> With -current there's essentially no pause in the > > >> stream of fresh commits, so git finds a new commit > > >> by the time buildworld finishes. > > >> > > >> Is there some marker or indicator that signals the > > >> -current tree is at least nominally consistent and > > >> buildable? I'm not asking if it'll work, just whenter > > >> it's worth a try. > > >> > > >> For example, my practice has been to run git pull, > > >> then make buildworld. If buildworld succeeds, I'll > > >> try another pull. If nothing new shows up then run > > >> install and reboot. This works with a stable branch, > > >> but with -current there are always fresh commits. > > >> > > >> I've tried looking at the commits to see if they're > > >> relevant to problems I'm seeing, rebuilding if they > > >> are and proceeding with install if they seem unrelated. > > >> > > >> Is this approach at all sound? Is there a better way? > > > You can follow the stabilization week mark. More information at: > > > > > > https://wiki.freebsd.org/StabWeeks > > > > > > > > > Note how this example would work by you [Bob P.] choosing to use > > somewhat older vintages that have been separately tested --based on the > > test results indicating evidence of some stability for your workload. > > That is instead of using the most recent commit that have not had later= , > > separate testing. > > > > The details of the specific testing seem unlikely to be biased to issue= s > > more specific to armv7 on RPi2 v1.1's or aarch64 on RPi4's, RPi3's, and > > RPi2 v1.2's. I've no clue how the testing would fit with your networkin= g > > context. > > > > The testing is generally monthly. (2024-Dec was canceled, for example.) > > > > "* Last week of a month is declared a stabilization week . . . For our > > purposes we will use the week that contains the last Friday of > > the month." Also: "Monday 8:00 GMT a tag is created and published. > > Right now it is published at [the glebius] personal > > https://github.com/glebius/FreeBSD/tags. Note that the tag points at a > > hash in the official repo, so there is no trust involved here." > > > > More from: > > > > > > > > QUOTE of what glebius wrote: > > At the end of the stabilization period be it Friday or earlier I will > > write email to current@ reporting the results: > > > > - were there any regression identified with the Monday tag > > - what has been accumulated in the stabweek branch > > - known stable point(s) of FreeBSD/main during the period, recommended > > for use > > > > The free riders who did not participate in the testing are now welcome > > to update their machines to published stable points :) More seriously > > speaking, I actually hope that in some future snapshots.FreeBSD.org wil= l > > start using these points for snapshot generation. > > END QUOTE > > > > > > As far as I can tell, use of stable points when fix hashes are involved > > means git branching at the (final) Start hash and then cherry picking > > the fix hashes for the Start hash into that temporary(?) branch: the > > result is not at some commit that is directly on main. (main could have > > had other changes mixed in that were not tested.) So it is biased to > > folks that use git somewhat more like a developer. Sometimes there is a > > "use hash" from main instead of cherry picking. > > > > The freebsd-current message closing the stabilization week is essential > > to giving context about what to do. > > > > > > I do not know how this fits with what you are comfortable doing. > > > > I think it's sensible to make a point of pulling and trying to compile > the source tree at the revision identified as "stable". > > It's slowly dawning on me that there are (at least) two different > aspects to my question. > > The intended goal was to find out how to avoid attempting to > compile in the middle of a commit process, where some files > are updated but others not, yet. It's unclear over what span > of time a commit, or set of commits amounting to a fix, takes. > If seconds, it's a non-issue. If a day, something worth avoiding > if possible. In theory, a commit should be a self contained entity, but in practice we all screw up sometimes. (One exception for me is bumping __FreeBSD_version, which I always do as a separate commit, but usually within minutes of the commit it is done for. > > Another aspect is avoiding trying to compile sources that > are complete as intended by the developers but which may not > run correctly even if they compile and install. This, more > ambitious goal, seems to be the point of stableweek. > > Broadly speaking, I'd like to avoid build errors if possible so > that test builds have a chance to crash. Up to now I've guessed > build-time errors are of the first type. > > It's my assumption that buildworld is hardware-agnostic: Sources > can be expected to compile without errors regardless of hardware > target. Whether the resulting binaries actually run as intended > on the target hardware is an independent question. Is this notion > incorrect? > > Thanks to all for reading and trying to enlighten me! There is a reason that "main" is not called "stable". Stabilization week might help, but it is really a pause in commits for new features while stability is checked and doesn't really imply the code will be stable at that point. (Maybe more stable at the end of it?) We (the committers) do try and keep "main" stable, but we don't always succeed, which is why "main" gets changes first and then they filter down to stable and release branches later. rick > > bob prohaska > > From nobody Sat May 9 16:51:20 2026 X-Original-To: freebsd-current@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 4gCX6t2bYkz6cB7c for ; Sat, 09 May 2026 16:50:46 +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 "pelorus.zefox.org", Issuer "pelorus.zefox.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4gCX6r5k54z3D9R for ; Sat, 09 May 2026 16:50:44 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of fbsd@www.zefox.net has no SPF policy when checking 50.1.20.27) smtp.mailfrom=fbsd@www.zefox.net Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.18.1/8.18.1) with ESMTPS id 649GpKQm062970 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Sat, 9 May 2026 09:51:21 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.18.1/8.18.1/Submit) id 649GpK3c062967; Sat, 9 May 2026 09:51:20 -0700 (PDT) (envelope-from fbsd) Date: Sat, 9 May 2026 09:51:20 -0700 From: bob prohaska To: Rick Macklem Cc: freebsd-current@freebsd.org Subject: Re: Update strategy and timing Message-ID: References: <9ed12219-6e78-4156-b0df-aca91a732127@FreeBSD.org> List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Spamd-Result: default: False [0.45 / 15.00]; AUTH_NA(1.00)[]; NEURAL_HAM_MEDIUM(-0.99)[-0.991]; NEURAL_HAM_SHORT(-0.54)[-0.544]; MID_RHS_WWW(0.50)[]; WWW_DOT_DOMAIN(0.50)[]; MIME_GOOD(-0.10)[text/plain]; NEURAL_SPAM_LONG(0.09)[0.089]; RCVD_TLS_LAST(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; MIME_TRACE(0.00)[0:+]; MISSING_XM_UA(0.00)[]; TAGGED_RCPT(0.00)[]; ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US]; TO_DN_SOME(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; FREEMAIL_TO(0.00)[gmail.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; DMARC_NA(0.00)[zefox.net]; R_DKIM_NA(0.00)[]; R_SPF_NA(0.00)[no SPF record] X-Spamd-Bar: / X-Rspamd-Queue-Id: 4gCX6r5k54z3D9R On Sat, May 09, 2026 at 09:07:47AM -0700, Rick Macklem wrote: > On Sat, May 9, 2026 at 8:57 AM bob prohaska wrote: > > > > On Fri, May 08, 2026 at 01:29:50PM -0700, Mark Millard wrote: > > > On 5/8/26 09:37, Renato Botelho wrote: > > > > On 08/05/26 12:48, bob prohaska wrote: > > > >> Is there a preferred strategy to timing updates > > > >> for self-hosted FreeBSD systems? > > > >> > > > >> On the stable branches it's easy; just update when > > > >> updates are announced and build/install. Once caught > > > >> up, things can be left alone for days at least.. > > > >> > > > >> With -current there's essentially no pause in the > > > >> stream of fresh commits, so git finds a new commit > > > >> by the time buildworld finishes. > > > >> > > > >> Is there some marker or indicator that signals the > > > >> -current tree is at least nominally consistent and > > > >> buildable? I'm not asking if it'll work, just whenter > > > >> it's worth a try. > > > >> > > > >> For example, my practice has been to run git pull, > > > >> then make buildworld. If buildworld succeeds, I'll > > > >> try another pull. If nothing new shows up then run > > > >> install and reboot. This works with a stable branch, > > > >> but with -current there are always fresh commits. > > > >> > > > >> I've tried looking at the commits to see if they're > > > >> relevant to problems I'm seeing, rebuilding if they > > > >> are and proceeding with install if they seem unrelated. > > > >> > > > >> Is this approach at all sound? Is there a better way? > > > > You can follow the stabilization week mark. More information at: > > > > > > > > https://wiki.freebsd.org/StabWeeks > > > > > > > > > > > > > Note how this example would work by you [Bob P.] choosing to use > > > somewhat older vintages that have been separately tested --based on the > > > test results indicating evidence of some stability for your workload. > > > That is instead of using the most recent commit that have not had later, > > > separate testing. > > > > > > The details of the specific testing seem unlikely to be biased to issues > > > more specific to armv7 on RPi2 v1.1's or aarch64 on RPi4's, RPi3's, and > > > RPi2 v1.2's. I've no clue how the testing would fit with your networking > > > context. > > > > > > The testing is generally monthly. (2024-Dec was canceled, for example.) > > > > > > "* Last week of a month is declared a stabilization week . . . For our > > > purposes we will use the week that contains the last Friday of > > > the month." Also: "Monday 8:00 GMT a tag is created and published. > > > Right now it is published at [the glebius] personal > > > https://github.com/glebius/FreeBSD/tags. Note that the tag points at a > > > hash in the official repo, so there is no trust involved here." > > > > > > More from: > > > > > > > > > > > > QUOTE of what glebius wrote: > > > At the end of the stabilization period be it Friday or earlier I will > > > write email to current@ reporting the results: > > > > > > - were there any regression identified with the Monday tag > > > - what has been accumulated in the stabweek branch > > > - known stable point(s) of FreeBSD/main during the period, recommended > > > for use > > > > > > The free riders who did not participate in the testing are now welcome > > > to update their machines to published stable points :) More seriously > > > speaking, I actually hope that in some future snapshots.FreeBSD.org will > > > start using these points for snapshot generation. > > > END QUOTE > > > > > > > > > As far as I can tell, use of stable points when fix hashes are involved > > > means git branching at the (final) Start hash and then cherry picking > > > the fix hashes for the Start hash into that temporary(?) branch: the > > > result is not at some commit that is directly on main. (main could have > > > had other changes mixed in that were not tested.) So it is biased to > > > folks that use git somewhat more like a developer. Sometimes there is a > > > "use hash" from main instead of cherry picking. > > > > > > The freebsd-current message closing the stabilization week is essential > > > to giving context about what to do. > > > > > > > > > I do not know how this fits with what you are comfortable doing. > > > > > > > I think it's sensible to make a point of pulling and trying to compile > > the source tree at the revision identified as "stable". Sorry, this passage is a braino. I should have said: ...make a point of pulling the main revision identified in the stableweek email... > > > > It's slowly dawning on me that there are (at least) two different > > aspects to my question. > > > > The intended goal was to find out how to avoid attempting to > > compile in the middle of a commit process, where some files > > are updated but others not, yet. It's unclear over what span > > of time a commit, or set of commits amounting to a fix, takes. > > If seconds, it's a non-issue. If a day, something worth avoiding > > if possible. > In theory, a commit should be a self contained entity, but in > practice we all screw up sometimes. (One exception for me > is bumping __FreeBSD_version, which I always do as a > separate commit, but usually within minutes of the commit > it is done for. > That's helpful to know. It sounds like the risk of pulling mid-commit is rather small on any given day. > > > > Another aspect is avoiding trying to compile sources that > > are complete as intended by the developers but which may not > > run correctly even if they compile and install. This, more > > ambitious goal, seems to be the point of stableweek. > > > > Broadly speaking, I'd like to avoid build errors if possible so > > that test builds have a chance to crash. Up to now I've guessed > > build-time errors are of the first type. > > > > It's my assumption that buildworld is hardware-agnostic: Sources > > can be expected to compile without errors regardless of hardware > > target. Whether the resulting binaries actually run as intended > > on the target hardware is an independent question. Is this notion > > incorrect? > > > > Thanks to all for reading and trying to enlighten me! > There is a reason that "main" is not called "stable". > Stabilization week might help, but it is really a pause in commits > for new features while stability is checked and doesn't really > imply the code will be stable at that point. (Maybe more stable > at the end of it?) > > We (the committers) do try and keep "main" stable, but we > don't always succeed, which is why "main" gets changes > first and then they filter down to stable and release branches > later. Understood, I chose my words badly in referring to stable above. I meant "the revision of -main referenced in the stableweek email". Thanks for writing! bob prohaska From nobody Sat May 9 17:53:01 2026 X-Original-To: freebsd-current@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 4gCYVz4zDkz6cH32 for ; Sat, 09 May 2026 17:53:15 +0000 (UTC) (envelope-from freebsd-current-freebsd-org111@ketas.si.pri.ee) Received: from mail.ketas.si.pri.ee (d004-fea2-0bff-021e-13e8-8437-07d0-2001.dyn.estpak.ee [IPv6:2001:7d0:8437:13e8:21e:bff:fea2:d004]) (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 mx1.freebsd.org (Postfix) with ESMTPS id 4gCYVy1Fqsz3P2h for ; Sat, 09 May 2026 17:53:13 +0000 (UTC) (envelope-from freebsd-current-freebsd-org111@ketas.si.pri.ee) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=ketas.si.pri.ee header.s=ketas-si-pri-ee-20240416002854-4096 header.b=Ey3QmmAN; dmarc=pass (policy=reject) header.from=ketas.si.pri.ee; spf=pass (mx1.freebsd.org: domain of freebsd-current-freebsd-org111@ketas.si.pri.ee designates 2001:7d0:8437:13e8:21e:bff:fea2:d004 as permitted sender) smtp.mailfrom=freebsd-current-freebsd-org111@ketas.si.pri.ee X-Original-To: freebsd-current@freebsd.org DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=ketas.si.pri.ee; s=ketas-si-pri-ee-20240416002854-4096; t=1778349183; bh=HqTqbqOTn+o6Nbjdiy9dNRAyHAti67O3Ir/ZxNbN5g0=; h=Date:From:To:Subject:In-Reply-To:References; b=Ey3QmmANQjpwONfnBD4x/HpjJ8jff6f5LqDmwA0EtLEsE8k3s4q/gAcctH9ci09qP eAkcns9fwXTOE51B/dcnrojioK4DlhA/zSfNp0H5SKlwUZuC64R99XxgsYeBoHK6V3 RBpp+QIsjCu8o/wac20qAVHXD+bPJh2PGUdFRWDlIyeQDA8ybkYP+KSnsxZ24guPL7 0Sw901cZ6AJM2Nh1KOw/Xplgo94aMOKv91I4bf084AXcIjw0E1DfNLF/22nBrUk5Jp UdBt0cRR5/j5+SEKO0BVcpJhUays3WY20NGzAUNq4vzu7upl9Lemx2q9rFK9ulNpj2 dgq/ysrPTV9po0TnCtm/vTDORrmfpFwirsXQKrReUcSlUz2EsIZqgptBQRw93Dkvv3 Ult1WCvBDaZowz+zLjUF4Da1ronaNWwZeWmtRTTdKYpqQd2fCD4Vb49l8qJUcmpKyE gYPxvacR/NHQlH318Wx6YRK6h58P8jVFj5yTpLJlnvOkO1sPzsJuiDpw8wC6zt6piv Q0kp5ukGlsAOgWwIBAe/+QVD+CxNuKNzXp+PSsWigxwf9PkKDK1vYlSr+3kPocCIpp sOA4AgWe7d+7TqkAl7um3W29fZac7uAwQtE1XPa0q+WKjbF5lae2BmUPyThdEbzRVG WN3Ii2m+9SSyxA7nKsGaZHlg= Received: from ehlo.thunderbird.net (0115-0000-0000-0000-13c8-8437-07d0-2001.dyn.estpak.ee [IPv6:2001:7d0:8437:13c8::115]) (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) (No client certificate requested) by mail.ketas.si.pri.ee (Postfix) with ESMTPSA id B66B55E4C6A for ; Sat, 09 May 2026 20:53:02 +0300 (EEST) Date: Sat, 09 May 2026 20:53:01 +0300 From: Sulev-Madis Silber To: freebsd-current@freebsd.org Subject: Re: Update strategy and timing User-Agent: K-9 Mail for Android In-Reply-To: References: <9ed12219-6e78-4156-b0df-aca91a732127@FreeBSD.org> Message-ID: <6DC7AD6C-4A29-4C4F-A8F8-77911D3564EE@ketas.si.pri.ee> List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spamd-Result: default: False [-0.79 / 15.00]; HFILTER_HOSTNAME_5(3.00)[d004-fea2-0bff-021e-13e8-8437-07d0-2001.dyn.estpak.ee]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.99)[-0.991]; DMARC_POLICY_ALLOW(-0.50)[ketas.si.pri.ee,reject]; R_DKIM_ALLOW(-0.20)[ketas.si.pri.ee:s=ketas-si-pri-ee-20240416002854-4096]; ONCE_RECEIVED(0.20)[]; R_SPF_ALLOW(-0.20)[+ip6:2001:7d0:8437:1300::/56]; MIME_GOOD(-0.10)[text/plain]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; ASN(0.00)[asn:3249, ipnet:2001:7d0::/32, country:EE]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_ONE(0.00)[1]; RCVD_TLS_ALL(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DKIM_TRACE(0.00)[ketas.si.pri.ee:+] X-Spamd-Bar: / X-Rspamd-Queue-Id: 4gCYVy1Fqsz3P2h i track current, currently only armv7 but i do that with even more caution i don't store anything important there, etc if you do all that and be prepared for any faults, it's fine my funniest issue was time jumping back and forth=2E i was surprised that = anything worked at all=2E turned out 4-core system had free running clock a= nd time came from each one randomly and they were not in sync actually fbsd current is surprisingly stable and therefore it's used in so= me systems to get latest features of course one needs to test even a release if it works=2E if not, report i= t=2E if does, use it i think we have enough cheap computing hw in 2026 that this approach works you can also watch this ml and commit logs for any ongoing issues, so you = don't build the exact bad commit=2E sometimes this is a thing provided you do all that, you can use current=2E like pocket knife, it's u= seful, despite you could cut yourself sometimes From nobody Sat May 9 21:28:06 2026 X-Original-To: freebsd-current@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 4gCfH56QCZz6cqHt; Sat, 09 May 2026 21:28:17 +0000 (UTC) (envelope-from vermaden@interia.pl) Received: from smtpo49.interia.pl (smtpo49.interia.pl [217.74.67.49]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4gCfH45rf5z3rsv; Sat, 09 May 2026 21:28:16 +0000 (UTC) (envelope-from vermaden@interia.pl) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=interia.pl header.s=dk header.b=R0DgTRFJ; dmarc=pass (policy=none) header.from=interia.pl; spf=pass (mx1.freebsd.org: domain of vermaden@interia.pl designates 217.74.67.49 as permitted sender) smtp.mailfrom=vermaden@interia.pl Date: Sat, 09 May 2026 23:28:06 +0200 From: vermaden Subject: PKGBASE Upgrade 15.0-RELEASE to 15.1-BETA2 To: freebsd-stable@FreeBSD.org, freebsd-current@freebsd.org, freebsd-hackers@FreeBSD.org X-Mailer: interia.pl/pf09 X-Originating-IP: 45.148.42.7 Message-Id: List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=interia.pl; s=dk; t=1778362088; bh=7mah372e0qRyO4V5AgTplie/rD2FmvqEZp5LNpyKJEU=; h=Date:From:Subject:To:Message-Id:MIME-Version:Content-Type; b=R0DgTRFJZa1XwQU9LS2pK0tiJrSktGJ44dkP0pBO/7xesdDuswlrCv3/ZWtG+qIqN rdU2k7KWaSkhye+FClEqpaccooRpwzx9iXkcsHDd5ONNUHKt5zsLHqAa72eGulfWAI fbo1uZJRAr7mnUJBI+is2Sf2HOz6xkUGkrC04VuE= X-Spamd-Result: default: False [-2.95 / 15.00]; NEURAL_HAM_SHORT(-0.95)[-0.946]; NEURAL_HAM_LONG(-0.86)[-0.857]; NEURAL_HAM_MEDIUM(-0.64)[-0.644]; MID_RHS_NOT_FQDN(0.50)[]; DMARC_POLICY_ALLOW(-0.50)[interia.pl,none]; R_SPF_ALLOW(-0.20)[+ip4:217.74.64.0/22]; R_DKIM_ALLOW(-0.20)[interia.pl:s=dk]; MIME_GOOD(-0.10)[text/plain]; ONCE_RECEIVED(0.10)[]; RWL_MAILSPIKE_GOOD(-0.10)[217.74.67.49:from]; FREEMAIL_FROM(0.00)[interia.pl]; MIME_TRACE(0.00)[0:+]; SUSPICIOUS_AUTH_ORIGIN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; HAS_XOIP(0.00)[]; TO_DN_NONE(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[interia.pl:+]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org,freebsd-hackers@freebsd.org,freebsd-stable@freebsd.org]; ASN(0.00)[asn:16138, ipnet:217.74.64.0/22, country:PL]; RCVD_COUNT_ZERO(0.00)[0]; FREEMAIL_ENVFROM(0.00)[interia.pl]; DWL_DNSWL_NONE(0.00)[interia.pl:dkim] X-Spamd-Bar: -- X-Rspamd-Queue-Id: 4gCfH45rf5z3rsv Hi, I was not able to find information on how to upgrade FreeBSD 15.0-RELEASE to 15.1-BETA2 in PKGBASE world. Its simple and known with freebsd-update(8) but a mystery with PKGBASE. Please advice. Thanks, vermaden From nobody Sat May 9 23:43:29 2026 X-Original-To: freebsd-current@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 4gCjHJ3Kwmz6d13k for ; Sat, 09 May 2026 23:43:40 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic309-21.consmr.mail.gq1.yahoo.com (sonic309-21.consmr.mail.gq1.yahoo.com [98.137.65.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 4gCjHG0WDwz3TRw for ; Sat, 09 May 2026 23:43:37 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=Wn+HlDwX; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.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=1778370213; bh=QzKL1Llh/9bFzxIJfh0II4Qsw5wSeD26t/Sp+mMaj4k=; h=Date:Subject:From:To:Cc:References:In-Reply-To:From:Subject:Reply-To; b=Wn+HlDwXFmdVJNqdDHpwuB2ec9qXyEiKR1gCg3To7XbgVJW9U870Zzv6aNhq9H+vQ613mkqkXn191FS6tACjjP6JNAx1XO+BXmgyKZXIIBwAm10aRJaSFif07CeErAyZFaaux4NskyoD2Cnjc7uyWcE2uYYAB0jyJ5HLmWtHGeNN3r9sbez/o7ERCz7A6UINx9PaXy3fM82dbe4SU0RNPP9GET6NPoF4D3Z/0ODCwTGDa+FROIQtG3RSYBz0fWcNgnskua9tIP5rtG8SeX8XVM3D6bRcpU7sA0JVHREDvCz+ski+kRyiWk+O+VtD0sj3Vy33oO6DXtAPbZMAJ3PLfQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1778370213; bh=jxNOPPi+Boiro1cxZBhQIqdoIOyevsx2KPzAGSYI1Dw=; h=X-Sonic-MF:Date:Subject:From:To:From:Subject; b=CR/kxuUbRPHr6iuBUzDQ6/aAubH9MR5msBTCjRY7UQnUouFyU44kxQd8COtjzxU32WxW53c++8zL54Nwt6fgpQHk2aV0bvcaBLj48w+z44mztplBdEdKAYIt2yyD2MlZYIE4q1wJYePVSx1+YzpoJbvEvpFYk+ppuDLwb/UZwojDoTUf7bgHB6DGGCGRO8N0ag7IIaX8416kPEBfaYwzoF0eFgue4TN6UBA3zaNlv++S0PMeXQyyXuNuowOPUOiZn0BCW5xkqmrLVBW3dDdL2qxGMy/diLfof93qGzI7/A+nLX8C5k+7E5+hnvod7SanHHWXFaoOar8I/hkDCmLfcQ== X-YMail-OSG: 52upOXYVM1kEaN4vrbl2kbjFzASZWsQTD.fM2OkiWEwBbaKKRDYwec9zSFuUm_T o9KGwUWyvK4MLan0tFlzN8fDc3az9oUBBiX24.WoowEudELlYqNku8ZENX4VEhMGpiiMd.ZxaeQr zyEr.j4bavlPO5YCyeWoLpA555NtYDjZ2uvI5DcX07VVZI5tDqeGF4EihxHdyi1HZdi2saexAg.2 N8iDZmzm1L9rNG38C0Y2V4eifNCLx96Go1CwFmNdS9A19xKObmBCu26Y8JMuOe_BY4jGD8bFr0UH Edvo0mBmpuDcqE1.vcg0J4tnx12SqsU2._klccBPKChnGcR3BDl0UdHHewQuN9Usg3JTfQHLqBOg lYvZaN3xQSQqf.7uG6IavZLx05Uu5a3VhwxwYKg_KH6npp9.IpjmDqi.i_LcKvqdpz.wlhEI9iRb nb2wjFfzbAj9nFGEAPgXUn7M_faQdemLZg9K98T8sXTRswfsGeHVJeawWau70jD948ihbrkSO3we g7BOBLBC3CH6L2Ra5mmCmdjll0f9EiDgizViRldC9XlIrws4mm3JpbCJ27uusYYmCXethO2gqQp. XJarL6ydpaIvnN7.CJK2lGHFFKkJJSopE39A_Xty97TLQNw7JovO.a1HHphH6KL0bVH9dsnHat3K C7kOpL1Ybhv8dw0wmn2V6qYo9qzsmUvEg18z_yxdiGPDRqe3pA.8N8fS4S5DeyFotmC4iPoolqt1 B95W8VC4POvzbQ4FlpHjUgqCXEZxgXJBadC3r0WjX8IHeMcs5bnf6FWEx7ncQeekIYyVc6S2DDOi Vxa8vhk2wQr1Iv2nDWYLKEm5l0q7_S6KZshkkXwNGMyplk2WrXGlTuZ0rZhu8XHY3rSknwJZ8ArP Ie6Y66.gBwjZ05ST3ji4EksDL4BBi7zR_bB4Z5i1llnTDqGQ108ObW0RqP7_iPRB5J5jtdKfKIle uP8W41q8iRZFXCZfg687wV1dATkwvJwBBv2glI2MDrloygd2OWud.KNKNQ2G9Dr33oSIImQBEqFT zoK.sE92rr88TuQQ1C.SKvzhvsQD3yqxFbIPQ718unllNb3A1Yot8UGbeXBlLh1fRDw65JIC4rfu 7zBcy4p7WI3NiHPkAGj8C1Ae6FY8EAwVUZUuenrxBktgMJl35xI1irrcEA9IeTVSQe7Z.3KV9s2k 4jwGkV4vjV._fwB__lap2ZHX0ugSVyd1Hr6YVUphdfav1bU31tRbnfw1ehNM9phQsrMWiNbIK7fG 6gWa0G34.gBrskq3oHtF9bzSSOa4YCwR3iyEENU4Vg12ik_ZQkBx1favosfkAmAO4XEoMW2Qn8Qa UqR1RkQdiM6mOJvVEGH1RWRPxgTMEwlmoeBhqb71ZCofYL905Mzfq_8QLblmOu6RIgFwfRtX8Ytd mAer70v7smJCDWTiW3tnsqajkkuRcjno.7vuSMKSO74AbGm2tP70KhlPnTsxyzyWUFZHjICkXrMU _jLXGm.AmrRcDjsiQCePOzWxNpLfSCBy2KAGht.bDlrm7NQLzD7ZyBFZyGbbXV.21yMVhXs7LGho wvSV_GJIk4Vq5uOxSkcNd9xiSztTzH2ZkkyJMIIbqjSZoqypGG1YJ2PzDGmSaqXW2kRqMzbzJixR V5IeFQ5BxqGmpD1BEyl8.XD9WicoBOg3cB3TB6QiUjp5.EnGW3Eb12UmULkLJyrw8cW_brJwQ8U0 q7Vz46ibbI_bLa9r.7pssbYbU6_6Gef4cBjpF6Tl8FK5OmBU_MAO.CI2ZDWc0ijlRQNjgfo2OXBW _DBLWPJ99H0v5fVxmHsFVQgAUof34TUgIpl9kN0Fs_uli1BFxTvL4vqVNVReND4BD9MCH2l2HeEL 9kJTnD8.VJIrhtbxkakpVBuKQJd9Tlp8GtEvEQKJlkxZfMnRvIsAfn.D_WbFueScyZdzPnasseJD nY3UB5GPCdkBaa8aMnQ4k9d1BsJMOwBVOXO4lgM6YHRa9xOpza9oMxoSe0vZeuk57Ju3DpdQycmK NwywYHhgN1hBGaKNZQMeiHJJRHpWVXMtDrg7E3xAX.TgVANFz0EgxfhWSDmwml3dYnb5hMK.jZ9M PyPxgoJtGRB7xlPS4ManP_eFyPwKTMpx8VLgd4vntM2KBup8oM7z5Yxma5TM7NtVq8GcFo20nAlC rdtBdt.4AUFcuqsQfxE2OxyAmpSxaEZSfno5Sv4aHxZQj69GTnv4m32rR20.WzncLffIyGTVDnM0 rOKEOCe15.NIzmSht74aV0w7hdOud2n2lp7zJ_BMljFUgQbk0Ovt_Rib6rOBpCoG0.J8FFoaFKhb xCrvwWWZ..aixBKBu3T.yDGvParfbgUxpJ96OzSontH3dCfLPYlntXA-- X-Sonic-MF: X-Sonic-ID: fb081bb5-7f77-466c-a1fb-172ea60cec97 Received: from sonic.gate.mail.ne1.yahoo.com by sonic309.consmr.mail.gq1.yahoo.com with HTTP; Sat, 9 May 2026 23:43:33 +0000 Received: by hermes--production-gq1-7bb7df5c46-bdzch (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 9a8191ecbca0bf428d812356a06a7fca; Sat, 09 May 2026 23:43:29 +0000 (UTC) Message-ID: Date: Sat, 9 May 2026 16:43:29 -0700 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: ar: error: libclang.a: 'ParseDecl.o': section header table goes past EOF [So far: unable to reproduce, even based on llvm19 involvement] From: Mark Millard To: bob prohaska Cc: freebsd-current@freebsd.org References: <2c2ab68d-83eb-4b6d-996d-10c2169a2165@yahoo.com> <4fab914f-ff17-4312-a098-975b6c103e05@yahoo.com> <413d71d1-6e18-4c7f-8844-d85c304d0504@yahoo.com> <33436574-0b2b-4db8-a69f-85df46af12a6@yahoo.com> <7e29fc11-9fcc-4a71-97bb-b709862e35e1@yahoo.com> <9ff7855f-2b48-4cac-a82d-2cbd9912dc27@yahoo.com> <6ae013cb-2e90-4e08-bac4-001fc8bc051c@yahoo.com> Content-Language: en-US In-Reply-To: <6ae013cb-2e90-4e08-bac4-001fc8bc051c@yahoo.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailer: WebService/1.1.25725 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.yahoo X-Spamd-Result: default: False [-2.42 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-0.99)[-0.988]; NEURAL_SPAM_SHORT(0.56)[0.563]; 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]; RCPT_COUNT_TWO(0.00)[2]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; TO_DN_SOME(0.00)[]; MIME_TRACE(0.00)[0:+]; 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]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; 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-current@freebsd.org]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.65.147:from]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.65.147:from] X-Spamd-Bar: -- X-Rspamd-Queue-Id: 4gCjHG0WDwz3TRw On 5/7/26 17:50, Mark Millard wrote: > On 5/7/26 16:46, bob prohaska wrote: >> . . . > > > I'm still no closer to having an idea what else to do for investigation. > So far, you have the only known example failure context. > > I've only had one idea for a very limited test sequence, based on referencing the Parse_ParseDecl.o.meta file: ) Start from a status of already having the bad Parse/ParseDecl.o in place. ) # cd /usr/obj/usr/src/arm.armv7/tmp/obj-tools/lib/clang/libclang ) # mv Parse/ParseDecl.o Parse/ParseDecl.o.bad (Or analogous. Below presumes that name I listed.) ) Execute the: # c++ -O2 -pipe . . . -o Parse/ParseDecl.o command listed in the Parse_ParseDecl.o.meta file. That command is long enough that simple copy/paste might split the line up into multiple lines. (I've run into such things in various contexts.) So care to get the command right/complete may be needed. The questions for the results are largely based on comparison/contrast with the original bad file: ) Does the command or the console report some sort of message that might be relevant? If yes, what are the details, otherwise conintue. ) Are Parse/ParseDecl.o.bad and the new Parse/ParseDecl.o the same by by size and (most?) content? If yes, you have replicated the problem and report that. (There could be timestamps or uninitialized pad bytes or such complicating the content judgment if the sizes are the same.) ) Is the new Parse/ParseDecl.o big enough compared to avoid the prior error messages? A simple command that would report the too-small size problem would be something like: # readelf Parse/ParseDecl.o readelf: error: 'Parse/ParseDecl.o': unable to continue dumping, the file is corrupt: section header table goes past the end of the file: e_shoff = 0x131190 If it does not produce such an error message, then things are very different. The file might even be correct to continue the build with. Report the status. At some point you will likely want to delete Parse/ParseDecl.o.bad . -- === Mark Millard marklmi at yahoo.com From nobody Sun May 10 01:41:50 2026 X-Original-To: freebsd-current@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 4gCltz4W70z6KLHr for ; Sun, 10 May 2026 01:41:15 +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 "pelorus.zefox.org", Issuer "pelorus.zefox.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4gClty5b36z3ghQ for ; Sun, 10 May 2026 01:41:14 +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.18.1/8.18.1) with ESMTPS id 64A1foT1085817 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Sat, 9 May 2026 18:41:51 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.18.1/8.18.1/Submit) id 64A1fojp085810; Sat, 9 May 2026 18:41:50 -0700 (PDT) (envelope-from fbsd) Date: Sat, 9 May 2026 18:41:50 -0700 From: bob prohaska To: Mark Millard Cc: freebsd-current@freebsd.org Subject: Re: ar: error: libclang.a: 'ParseDecl.o': section header table goes past EOF [So far: unable to reproduce, even based on llvm19 involvement] Message-ID: References: <413d71d1-6e18-4c7f-8844-d85c304d0504@yahoo.com> <33436574-0b2b-4db8-a69f-85df46af12a6@yahoo.com> <7e29fc11-9fcc-4a71-97bb-b709862e35e1@yahoo.com> <9ff7855f-2b48-4cac-a82d-2cbd9912dc27@yahoo.com> <6ae013cb-2e90-4e08-bac4-001fc8bc051c@yahoo.com> List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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: 4gClty5b36z3ghQ X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated On Sat, May 09, 2026 at 04:43:29PM -0700, Mark Millard wrote: > On 5/7/26 17:50, Mark Millard wrote: > > On 5/7/26 16:46, bob prohaska wrote: > >> . . . > > > > > > I'm still no closer to having an idea what else to do for investigation. > > So far, you have the only known example failure context. > > > > > > I've only had one idea for a very limited test sequence, based on > referencing the Parse_ParseDecl.o.meta file: > > ) Start from a status of already having the bad Parse/ParseDecl.o in place. > > ) # cd /usr/obj/usr/src/arm.armv7/tmp/obj-tools/lib/clang/libclang > > ) # mv Parse/ParseDecl.o Parse/ParseDecl.o.bad > (Or analogous. Below presumes that name I listed.) > > ) Execute the: > > # c++ -O2 -pipe . . . -o Parse/ParseDecl.o > > command listed in the Parse_ParseDecl.o.meta file. > > That command is long enough that simple copy/paste might split the line > up into multiple lines. (I've run into such things in various contexts.) > So care to get the command right/complete may be needed. > > The questions for the results are largely based on comparison/contrast > with the original bad file: > > ) Does the command or the console report some sort of message that might > be relevant? If yes, what are the details, otherwise conintue. > > ) Are Parse/ParseDecl.o.bad and the new Parse/ParseDecl.o the same by by > size and (most?) content? If yes, you have replicated the problem and > report that. (There could be timestamps or uninitialized pad bytes or > such complicating the content judgment if the sizes are the same.) > > ) Is the new Parse/ParseDecl.o big enough compared to avoid the prior > error messages? A simple command that would report the too-small size > problem would be something like: > > # readelf Parse/ParseDecl.o > readelf: error: 'Parse/ParseDecl.o': unable to continue dumping, the > file is corrupt: section header table goes past the end of the file: > e_shoff = 0x131190 > > If it does not produce such an error message, then things are very > different. The file might even be correct to continue the build with. > Report the status. > > > At some point you will likely want to delete Parse/ParseDecl.o.bad . > It looks as if running make kernel-toolchain somehow worked around the failure. It completed successfully and is now running a normal buildworld, which is in the building libraries stage. Hopefully it'll finish within a day or two. Thanks for writing, apologies if I jumped the gun! bob prohaska From nobody Sun May 10 03:56:32 2026 X-Original-To: freebsd-current@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 4gCpvD28j4z6KWcW for ; Sun, 10 May 2026 03:56:40 +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 4gCpvC2Chxz3x5V for ; Sun, 10 May 2026 03:56:39 +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=1778385395; bh=6CtM+5OCALMS/GRe4gt7x4R3f8KpfvnUnbb6kzRDhcY=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From:Subject:Reply-To; b=bzMjNxJLS6YEO6BYJQVqgJLubqpgNDNsJN+XVBLlpV5IIUvSCLpMLPwdV8lI0xNu3kqKloPeK4ZR8SGk7L2Lgm4cVXRVrBm21hcRa2C8ndFDwof0fAvGSyJXequoEQZsxU1SfSN1Pw0HCjU59uk2RWGUECAtsPG0Uq26WH2B6tsRIuIOz7kR7ZDzpu0vqqHj/R1nlO26c3GBnRx6EFoORwgNMj0FdzroG0aR3VdbT21IFc3pa5cK25xwyBfyybDLABvLk9zImV2W6pVHaJOmWomNZHNr79KiVzPSL6yMmefsVWQmm7oM7B6Ds64cPSeSRZDLbR8HQrJeVxJGZdMRmA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1778385395; bh=YaoWPrcaI5rp/c6rNuyMhmXMDb2E6QQKLbwWofbmOCB=; h=X-Sonic-MF:Date:Subject:To:From:From:Subject; b=KEJyRi3mkdU12wZQzzxCau0LK2p12H6EB2MEfVAkH6GtrDkclfjLu1v0bNVsGtCSygw9b8QMnbzC3G4cg7C1GvdR5UU+wqZtU3dh8GAAoOClL7QhX5Zkx9x6BP5eLdcJ+AMIVMrT4Ky1tYHVZhDJrgo9YNwJcR5EvbSNEZRyY2t5dQbik7r0rRIhc/3KW4sALxT2FUEmbHVbx7V/05mf1/K6Qy7wDmd5x9ovrX5Fnnfde2Pr7qRqoAWp3h2tngUhk2NCisTup2560SbVrOfAUBEUc3rcfGUFL4m3eOvHD5rR79hZLndBQrBmh0H48wEqpyqA2cIa3UYhI5+LuPnDkg== X-YMail-OSG: FFCpYukVM1kP.UxHUXIli.Jr4uzgIIPE4Cl2ZUvScVbTt5GMIOKYap0EKTPxrLw xEr.Lfk5KJsTGrryPZm4Nbb6RKFQvkbhsWwZiVqIbwF6GlJMy0F_2x6hJxTAJ5GpSDjJQm3fVA_b S4s4EWMps4jVWSPnRo2G0MOUfczcD.oj2GxdsVSqBQ7v0bsvha0WZcAbKZz486c0kjEnZtEpZXbf ZQ6EemNIS8HwbPTPJMEKWr9.VSeQRSZzqntjgH8CU8lsWjKqCwadFsMnznKr9CFavRKmHPeMxCTR E5h2kbq_S1e4P9uSp7H22avYOMNsw2f2nLY8rQqtpDVRLyFnblQ3VAQOLeyYhcEYdhxwgN0cKB1m 8Ye9v_1uWyOPHVvgRlXi3KS3HJJwZl8MtGeDW7uea7i23M6Nb7UTbrtjbBSUSJYxhvokWniDs0wC 8bqP7zsGvXrtAvtcBAbcej9TwhwihGKdgW0B4Lh..j5Uf2tf_0Qk0TOu8VQlkE1cJAJ_6EBOx8ac dXlIOUzcASbjv4_g_EBpl5h57IXao3itUNxQa8JixHgd1pfQ8_TuzToYUPOX9PpqtkwIyKu4p41B Idi5gDGxtWB84V2fWhqE_QFKWPxhrMSuyTqVgE7S9yDVCpwP.r3Qq..CHoiIz_VQ1ibRgPRPs5El hWhVg4OMRiTwscJQ1DEPdpCm1I0YE.ABWzL1m84_HiOEKpzp5lugFHY5VGy_Z.mrd2Js5f0WOXeK 6.z9r1k_OUo.sNB3GBkCo.VsxaYsQ9Dwiaxpt9EahhRkA5i3fpvqBclKUQEX7RO6M7.Lwzo6dnbb ___YAIftRsWKn2.xgpRDhNR7At1Q82JkXkQkHpn.pw8rNF1qjjLP51Tt7QRgkw_7mHRn8u0_3LNv irZKWpEsk8UJ9Ebmqe9bVnKdo2lxi.eBRb95a1LBvH145HygWiz3ZiCPAHKtYl8mwXAZBB6EIe8A T3J8021h5GQwhIw_rMqfS3rkkJ1JRYm49tr2LLzFxjmfkpKnMdkeGqlWGRSPAOMmtvPKskYcSwzp A4jzbFSXrqxnGzVeltndBhGF_OLs9VPhF7ocZdiAdz4.utpozBh3kx8XDjhyY_5oowy_euWuaQ.F yTk0ve85lPZoS8zqKe29dyEXO4_zRDq1Ki6rCsYxWqdRY.NhdVt7agZ1p1cPEB6sA2.EqPhl.BKp CzEzQm1pb73hRCYzMe1Ek4sLoN1.l99VRYF85ilnWYVBYyIIPrGNTTZjgu0RePuN3qP6Xo5Ni4CK 8VISvH1eFxWqg.oxfpAykR8xrcge._wly_7uTOZmOryhpE9mQQivpOONYrV7aLPmFeIPy_jas8kK CZD5hOdWPDVvXfIb99TQKcK3jKLQnW4HZb.kuqqYCqbTJpyNXwEc3w6cmxwVPCJj.xTjZ0Vgebo_ EYUyvl2iMmNiICUjqcZ3.KWWGYfA04TqqbW4nqjmajAbHCGZqvyElF3THYqHMUQnTQCou4uVUR6S F7FKpp5WO2FT8nOTi8.xezW_m7qMKuWbF2KVEqTygEUGw9VbB01SCW7iFlgZDoVnyO8ZymR82Mi4 Owud_fKBCqbpkOgFeqt.Xx67dySBACJlMIgGcprZ91Vk6uazZsTDrtL3yyxKykbREM6VLtbmU6Lx 9VdlPhh7dqD1mglr774UYk8_GcJsYFad30E40qJUASwXYjcl24db0Oq78cm40C2N8NFFXjt8qfw_ kB1.iOO_f4kGpT7BWl_t8_rrgtLiDPtBLripcMXStBZ.NWxWEElR8QVJFH3TIkAekvvNmFRA1ixr JqjB.57uiZZfhibZCL2LqNCq0HAYpvucQqaDU7Hv9MMbredASC.d3_BR1fezD8wzn8tLjkO0fRmF CH7uCUFmxy4CpLwAIyszL_7D7El7qdbPpJn0jHGSsLHRmsp2Ca2JES2mU7YSSuAcvk.SCyzg6cu5 qMu8hesy9wo89rBu4GNlAQMXFgWGETIPzAx_tJbb6AsARQk_RJ87s5WfueMIY55XdIwMBxTIohXY baiEFHmr6QL_PHgrdBNdLAqgohL2WVyoyXnJIrCvtqRaZo6Pqpg4q16P4qawlqBCtD_d1fAI9XyA iKhibYfoi3fxilteAgviV78YBmcOVtFqq8crBWJ6G5pUsbxzlPaqzgnyJR0jm3_qr7T19svod.B6 1UZ.NrkNnT1BsuCc0mB6ewuVKyP6yKLBWU4MGEAR94wMwkkEBL3MnMIHrTY.ZIJGll8HyGd7YNG3 DFDgFX39e5OAxkeb99Liz3eCJGVhWxp4Q2d.ZPDMolQ.KSfD6TB64tuLq5acMFV7QeEv82x4A X-Sonic-MF: X-Sonic-ID: 30d17ceb-0056-46ab-8d41-32a4a993f2ab Received: from sonic.gate.mail.ne1.yahoo.com by sonic309.consmr.mail.gq1.yahoo.com with HTTP; Sun, 10 May 2026 03:56:35 +0000 Received: by hermes--production-gq1-7bb7df5c46-2fd46 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 66243f74d3b6949a3a3bf3ccb7d054c7; Sun, 10 May 2026 03:56:33 +0000 (UTC) Message-ID: Date: Sat, 9 May 2026 20:56:32 -0700 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: ar: error: libclang.a: 'ParseDecl.o': section header table goes past EOF [So far: unable to reproduce, even based on llvm19 involvement] To: bob prohaska Cc: freebsd-current@freebsd.org References: <413d71d1-6e18-4c7f-8844-d85c304d0504@yahoo.com> <33436574-0b2b-4db8-a69f-85df46af12a6@yahoo.com> <7e29fc11-9fcc-4a71-97bb-b709862e35e1@yahoo.com> <9ff7855f-2b48-4cac-a82d-2cbd9912dc27@yahoo.com> <6ae013cb-2e90-4e08-bac4-001fc8bc051c@yahoo.com> Content-Language: en-US From: Mark Millard In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailer: WebService/1.1.25725 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.yahoo 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: 4gCpvC2Chxz3x5V X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated On 5/9/26 18:41, bob prohaska wrote: > . . . > > It looks as if running make kernel-toolchain somehow worked around > the failure. It completed successfully and is now running a normal > buildworld, which is in the building libraries stage. Good. What was the context like just before you ran kernel-toolchain? Had you cleaned everything out to start over? Or was the old bad file and related materials still in place? Was this jsut after doing another source update? When you did the kernel-toolchain was it -j1 (or no -j at all) style? Some other -jN ? How did that compare to prior build attempts that failed? Does the Parse/ParseDecl.o file look appropriately sized now? (My guess is: yes.) > > Hopefully it'll finish within a day or two. > > Thanks for writing, apologies if I jumped the gun! You have no reason to be waiting for me. > > bob prohaska > > > > > -- === Mark Millard marklmi at yahoo.com From nobody Sun May 10 10:20:57 2026 X-Original-To: freebsd-current@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 4gCzS1403Tz6cMRR for ; Sun, 10 May 2026 10:22:09 +0000 (UTC) (envelope-from Alexander@Leidinger.net) Received: from mailgate.Leidinger.net (bastille.leidinger.net [89.238.82.207]) (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 (prime256v1) client-digest SHA256) (Client CN "mailgate.leidinger.net", Issuer "E7" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4gCzRz0vG2z3TQJ for ; Sun, 10 May 2026 10:22:07 +0000 (UTC) (envelope-from Alexander@Leidinger.net) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=leidinger.net header.s=outgoing-alex header.b=svFH1kg8; dmarc=pass (policy=quarantine) header.from=leidinger.net; spf=pass (mx1.freebsd.org: domain of Alexander@Leidinger.net designates 89.238.82.207 as permitted sender) smtp.mailfrom=Alexander@Leidinger.net List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=leidinger.net; s=outgoing-alex; t=1778408514; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type; bh=Cve0TIWa9zYNdIEO3AtYK49GB7nClP963DI/pMH23Io=; b=svFH1kg85C/wp4jhoU4X/VRh++5yAl6ShJnowWdcaYylxGtilBdcP7eIBqcCLDmVdmGtZ3 XiTN8GnElKQzSsGSdufDWgxL9gpB1oQN8ygNe+N+lJDbQkUB5fdwcCsFzGaNwttP5wyrNg Mrx0/ImgenB2p1wFBTWy3QXGjiZ5aUsjWuYPS9/xirSP5hb+Xt4xWuARsJaw/k74I6vv2I F8BH+b3N8+VD0Z1QHYrJkO1iQiltgQlDSZIidIx4EscQEex2hQZAlHgR63xcdk3utAr0XV EiO1BsQ7nY1T0lUqTNkEkkkykbkRADJgnZmlMd5tyipRHqOyhuQVhDek2jjJAQ== Date: Sun, 10 May 2026 12:20:57 +0200 From: Alexander Leidinger To: Current FreeBSD Subject: fstat: znode_t size mismatch, data could be wrong Message-ID: <8960abcafb7ccc174439b9f10d583860@Leidinger.net> Organization: No organization, this is a private message. Content-Type: multipart/signed; protocol="application/pgp-signature"; boundary="=_81b8fee6953ab3377cfabb73089367aa"; micalg=pgp-sha256 X-Spamd-Result: default: False [-5.94 / 15.00]; SIGNED_PGP(-2.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.94)[-0.944]; DMARC_POLICY_ALLOW(-0.50)[leidinger.net,quarantine]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; R_DKIM_ALLOW(-0.20)[leidinger.net:s=outgoing-alex]; ONCE_RECEIVED(0.10)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; MISSING_XM_UA(0.00)[]; ASN(0.00)[asn:34240, ipnet:89.238.64.0/18, country:DE]; ARC_NA(0.00)[]; HAS_ORG_HEADER(0.00)[]; HAS_ATTACHMENT(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; RCVD_COUNT_ZERO(0.00)[0]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[leidinger.net:+] X-Spamd-Bar: ----- X-Rspamd-Queue-Id: 4gCzRz0vG2z3TQJ This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --=_81b8fee6953ab3377cfabb73089367aa Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed Hi, /usr/src and world are in-sync. A crashdump still produces a lot of: fstat: znode_t size mismatch, data could be wrong Any ideas what could be wrong here? Issue in src or something not ok in the installed world? Bye, Alexander. -- http://www.Leidinger.net Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.org netchild@FreeBSD.org : PGP 0x8F31830F9F2772BF --=_81b8fee6953ab3377cfabb73089367aa Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc; size=833 Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEER9UlYXp1PSd08nWXEg2wmwP42IYFAmoAXBgACgkQEg2wmwP4 2IbkiQ//YDg0+SVvzj6vGhyKReeZ6fmck+52W37eOvySOXcXqxsboOXL/Wrg8f8v dL0SbT0dEM6GTKPOYd/uY37Xf82EmP5A2+eRGMdAz04eAxBFvWG0cun79tSxalp2 JybJRXw4l2DuM8ziJqAJ7zu915h+N7e7hSYHcep2GRs1nAJx03yMiVPPzh22PUMN VKvrWlQsNwSpkS/00vLZpAcq309uEUezQo8cqIOV6ZvxZl3C29HZBvIGjG8tdKty /rCL1qONlO/2BTGJCd2pjUDwb2jUzHPhNRyoz69ql3ZQxtHPfSFo7AHecIdQ7Fv9 XTXNGDsxm4lvAPVe6XS5CUv/3s8qvTw3HXDOWA7Bik3iK56p6UsDtLykJrUQ0dbY 79MQfkX8mNd9RVdwj//zrfEe9+nsea/Daq7s6mSarOe6z+A7EXOL81vKhsiOWXj0 LqPay7j4Jk4oNNCdekrFXuHSOkeX2TGVTjjihfbTqSB8wheM6AqdiATulWyMJT94 Q/7mEIGyyca9DcOXdi9F9BshqAIxIK59QZRdkV0FyPtAkKo+V1ZFNY/A1KdD3gnz K4PBDB9g57K9CBy/P/MZVU/tVU8ZgNSrkqPT8bQdrp4Ee8dKFBJTjuXAiMZ1SPZ8 +jGKBjKCgBoQKHQU+PeACYOgh3Wy6F7bihuQXWmOR3KzF+VKqN8= =E2J1 -----END PGP SIGNATURE----- --=_81b8fee6953ab3377cfabb73089367aa-- From nobody Sun May 10 10:25:14 2026 X-Original-To: freebsd-current@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 4gCzXD3lV5z6cMgr for ; Sun, 10 May 2026 10:25:48 +0000 (UTC) (envelope-from Alexander@Leidinger.net) Received: from mailgate.Leidinger.net (mailgate.leidinger.net [IPv6:2a00:1828:2000:313::1:5]) (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 (prime256v1) client-digest SHA256) (Client CN "mailgate.leidinger.net", Issuer "E7" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4gCzXB6CbXz3VjM for ; Sun, 10 May 2026 10:25:46 +0000 (UTC) (envelope-from Alexander@Leidinger.net) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=leidinger.net header.s=outgoing-alex header.b=Qcv634rw; dmarc=pass (policy=quarantine) header.from=leidinger.net; spf=pass (mx1.freebsd.org: domain of Alexander@Leidinger.net designates 2a00:1828:2000:313::1:5 as permitted sender) smtp.mailfrom=Alexander@Leidinger.net List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=leidinger.net; s=outgoing-alex; t=1778408733; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type; bh=UKY9ZRO3unFWsIYMBxMbF6ryXSDXqZ+3Bk0GER5C9t8=; b=Qcv634rwezUkleqS8i4vJ1BNaabtEuUCqMVeodFRse93a+1RTgDSa22liOK+DEhOoB+avd Pfz2uG4cXedUu9iEI7HBl08APVyZkIkoFIRYy8yyL+Ge28GQQdcoeyI69IC3rQcKf40Gg5 5+L0Wmn6X/QoRia46+lJzOUSY6FSOM/yVoM4t/yrY29DzWNjcQ+B1dU3q+1mOiJ6DkfuhH n40zoziwVdPbHf4FBV5AsDUbbuKkYp+LJzUJ1pVKXKvcelPDNoJeG0cvAEN1lpBGOv77KF JRlE2UtiXBEErAR8oM265vErVJxXC+6mzSK9wIctFp7+gljQxuWyoeGmuyK8zg== Date: Sun, 10 May 2026 12:25:14 +0200 From: Alexander Leidinger To: Current FreeBSD Subject: Crash in network code Message-ID: <433e69057d938eb5280a08d758234ee6@Leidinger.net> Organization: No organization, this is a private message. Content-Type: multipart/signed; protocol="application/pgp-signature"; boundary="=_153ac07d4067ccff74dfa6ee692ef5fd"; micalg=pgp-sha256 X-Spamd-Result: default: False [-6.09 / 15.00]; SIGNED_PGP(-2.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.99)[-0.985]; DMARC_POLICY_ALLOW(-0.50)[leidinger.net,quarantine]; R_SPF_ALLOW(-0.20)[+mx:c]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; R_DKIM_ALLOW(-0.20)[leidinger.net:s=outgoing-alex]; ASN(0.00)[asn:34240, ipnet:2a00:1828::/32, country:DE]; ARC_NA(0.00)[]; HAS_ORG_HEADER(0.00)[]; MISSING_XM_UA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; HAS_ATTACHMENT(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; RCVD_COUNT_ZERO(0.00)[0]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[leidinger.net:+] X-Spamd-Bar: ------ X-Rspamd-Queue-Id: 4gCzXB6CbXz3VjM This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --=_153ac07d4067ccff74dfa6ee692ef5fd Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed Hi, This is with a src from 2026-04-29-222746 (with a patch for a ZFS panic): ---snip--- #7 m_mbuftouio (uio=uio@entry=0xfffffe085f2f9dc0, m=0xdeadc0dedeadc0de, len=len@entry=3414) at /space/system/usr_src/sys/kern/uipc_mbuf.c:2117 progress = 3414 total = 3414 length = error = #8 0xffffffff806038e3 in soreceive_stream_locked ( so=so@entry=0xfffff80482cd0000, sb=sb@entry=0xfffff80482cd0200, psa=, uio=0xfffffe085f2f9dc0, mp0=0x0, controlp=, flags=flags@entry=0) at /space/system/usr_src/sys/kern/uipc_socket.c:3430 len = 3414 error = n = oresid = 3414 m = #9 0xffffffff80603655 in soreceive_stream (so=0xfffff80482cd0000, psa=0x0, uio=0xfffffe085f2f9dc0, mp0=0xde, controlp=0x0, flagsp=0x0) at /space/system/usr_src/sys/kern/uipc_socket.c:3522 sb = 0xffffffbf flags = 0 error = 0 #10 0xffffffff80604263 in soreceive (so=0x0, psa=0xffffffbf, uio=0xffffff01, mp0=0xde, controlp=0x4a3f8da1f6bbbd01, flagsp=0x13cf3c6cce71a2e) at /space/system/usr_src/sys/kern/uipc_socket.c:3716 saved_vnet = 0x0 error = #11 0xffffffff805c6485 in fo_read (uio=0xfffffe085f2f9dc0, active_cred=0xffffff01, active_cred@entry=0xfffffe085f2f9d70, flags=0, td=0xfffff8001f9a5780, fp=) at /space/system/usr_src/sys/sys/file.h:364 No locals. #12 dofileread (td=0xfffff8001f9a5780, fd=43, fp=, auio=0xfffffe085f2f9dc0, offset=-1, flags=0) at /space/system/usr_src/sys/kern/sys_generic.c:369 ktruio = 0x0 cnt = 3414 error = #13 kern_readv (td=0xfffff8001f9a5780, fd=43, auio=auio@entry=0xfffffe085f2f9dc0) at /space/system/usr_src/sys/kern/sys_generic.c:290 fp = 0xfffff805bb8ab0f0 error = #14 0xffffffff805c637e in sys_read (td=0x0, uap=) at /space/system/usr_src/sys/kern/sys_generic.c:206 auio = {uio_iov = 0xfffffe085f2f9df0, uio_iovcnt = 1, uio_offset = 3413, uio_resid = 0, uio_segflg = UIO_USERSPACE, uio_rw = UIO_READ, uio_td = 0xfffff8001f9a5780} aiov = {iov_base = 0x1b3248a1c062, iov_len = 0} error = ---snip--- Does this ring a bell for someone? The system was up for about 4 days and I have no idea how to reproduce. Full kernel dump available. Bye, Alexander. -- http://www.Leidinger.net Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.org netchild@FreeBSD.org : PGP 0x8F31830F9F2772BF --=_153ac07d4067ccff74dfa6ee692ef5fd Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc; size=833 Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEER9UlYXp1PSd08nWXEg2wmwP42IYFAmoAXRgACgkQEg2wmwP4 2Ib/jRAAqd/nXQdayJumklXLNLifJ12xd91inyWoZB7WOiACTZZ2DccUmyFx9Eiz PYr+KBuusa/zz2HqXGxu8erCS0mXMr5kWSKcANBPYxz4YTWh+MaAgTdm0m4wg6ev 6HB5GZDFTr4kgqiDAqvWvRoI2xWAL3kXzckKh7WrDTHhUWvk5lWbxxuZ2AXvncsz zB3LXZDHycMghEDvmHCGEnetuLOmJtA+PrYPJlEFJURtfSQDrCznofCGatXVkpjX 8skMiDY0EvdGGlRcpM4nir5aNf7b+vyTvxE1XZVidz3dtZU7VLW6FVEAxrBA7Ou4 zapXZdynYOl055vEbLCVOuDv5AfsTegLNbcqO4rlDH9AhjyqAoaUpOP87NdeBq9M DtCwIXwMQ5tKUVh6DWy5IhPmNO4dqrrmZHYTzd2Ua9P8KhDNDR2EyHSmXOB0MYi5 SlKLT3K/fW/m70vihpn+hM5h77vLMR2WjG+UZ396ndlXDmgFe89jR/a+mUt7TP47 o2QksbjTqb3XzZnYCcPJUv/oieUNc81yRKtRsshKLlnUtCc0/6/8MgT65FEQCIIv 6df8JAZ94qygea/Aam8rnwgklNeYqBXY6aS1plssKlD/Oxe7LxA5eBoMQuVHiuDA /3DT/8Sf9Cd13tjZsQ7Neump6yjvSnfboZ3Tm66IjEh8qSJE5Dg= =9B/3 -----END PGP SIGNATURE----- --=_153ac07d4067ccff74dfa6ee692ef5fd--