From nobody Sat Feb 18 23:26:30 2023 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 4PK4Zf5zN2z3s3Bh for ; Sat, 18 Feb 2023 23:26:50 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Received: from mail-pl1-x632.google.com (mail-pl1-x632.google.com [IPv6:2607:f8b0:4864:20::632]) (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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4PK4Zd10LDz3sC9 for ; Sat, 18 Feb 2023 23:26:49 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=eFz1SZSn; spf=pass (mx1.freebsd.org: domain of rick.macklem@gmail.com designates 2607:f8b0:4864:20::632 as permitted sender) smtp.mailfrom=rick.macklem@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-pl1-x632.google.com with SMTP id o9so1709312plk.12 for ; Sat, 18 Feb 2023 15:26:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=C8LMPoFAJT4by0rsmynrXwV1+HRJC9R4dWmvc8xS/8s=; b=eFz1SZSnL2hxq0VuIuxHkqRYBrc4aoh1KFx9kOuWeFtJpt+vhI7clvYzUeP0lold2z 6a/CO3wjFW9qDud97fJYZ5aElSfR8vdF7o/oI00RT5xlnWKBN3cBr1ctsl+TDGk9aBIp baJv/wAJzOGigPFo6Lkevh9x2R4yVnAVU6i14tN31pT5GkafOPTfbH/EeTxtY7IzhdIL gdb9Szz9dtFvVGN9nGf+Z5rsAPt7ozEI8Renzh1cuoOI7Xx0iOOymvhlI8we3vpx4Vba dftbNQ34SPaHeWhTrSjyo6tmAgHAkic20eHs01XMSFIGFFQ/bBB4T5F2GjD6YJhsC3Kh yVtg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=C8LMPoFAJT4by0rsmynrXwV1+HRJC9R4dWmvc8xS/8s=; b=67u9CEpKdTQMzWqMftWo5C3rF6K52SmyHCYZvJdF3qIwaRWFy4iI6sWttApVuMosT0 kvLkrFyZPRoJ7ZFV3fJKyCf31SCeloq0RgTW5zAm8njuw7WAxxMbMG2jcAg5Fodixfof jgrv4WXJ+sWFpUysuhYswU4Rg1NfuX2AJhnrB79Uu+uBZFMeMwP+6mbCAPpGVE1WQSnP DoFsBoHFPNvRK1BBm0vMFSjUB0k5ZuBOv3eARH8aAmgkonNO9GYMw8qk5cKJWrk3XBC+ wGmHwhNDc9lPqAzmfZZ04mrljLYr0vqt3PlGfcguKuy5GvF6nnoZBqMof/bvbQVc7UY4 /O0w== X-Gm-Message-State: AO0yUKXgD+DJ0Lu4kIoaTqgbQLb2U4YUIjeDD1No0Fz24Yt8WuWwbWC3 ERVnd6wtbkGOE2x1DabJGfjtMFGCxHMIYaH5SUYNRLcuEQ== X-Google-Smtp-Source: AK7set+hXlOkcwZ+RlYn8rZ7NMh4cKWGBHd97sLs3Goao5HjJHXh+Untfg//vjPGTE3/akogzUTlXdpFLpUb4HGp7Bk= X-Received: by 2002:a17:90b:254b:b0:234:96b1:453a with SMTP id nw11-20020a17090b254b00b0023496b1453amr305738pjb.79.1676762807569; Sat, 18 Feb 2023 15:26:47 -0800 (PST) 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 MIME-Version: 1.0 From: Rick Macklem Date: Sat, 18 Feb 2023 15:26:30 -0800 Message-ID: Subject: Heads up: vnet'ng of NFS server turned on To: FreeBSD CURRENT Content-Type: text/plain; charset="UTF-8" X-Spamd-Result: default: False [-3.90 / 15.00]; NEURAL_HAM_LONG(-1.00)[-0.999]; NEURAL_HAM_SHORT(-0.95)[-0.954]; NEURAL_HAM_MEDIUM(-0.95)[-0.947]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; MIME_GOOD(-0.10)[text/plain]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; RCPT_COUNT_ONE(0.00)[1]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::632:from]; ARC_NA(0.00)[]; TAGGED_FROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; DKIM_TRACE(0.00)[gmail.com:+]; TO_DN_ALL(0.00)[]; MID_RHS_MATCH_FROMTLD(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FREEMAIL_ENVFROM(0.00)[gmail.com]; RCVD_COUNT_TWO(0.00)[2] X-Rspamd-Queue-Id: 4PK4Zd10LDz3sC9 X-Spamd-Bar: --- X-ThisMailContainsUnwantedMimeParts: N Commit ed03776ca7f4 enabled the NFSD_VNET, KRPC_VNET and KGSS_VNET macros. Kernels built with "options VIMAGE" now have a bunch of global variables used by the NFS server vnet'd. It is not quite ready to run the NFS server in a vnet prison. There are still a couple of patches in D37741 and D38371 needed to allow mountd(8) to run in a vnet prison and do exports within that prison. Once these patches are reviewed/committed a simple patch to kern_jail.c to enable "allow.nfsd" without VNET_NFSD defined will complete the kernel changes needed; All that is needed in userland are some small tweaks to the /etc/rc.d scripts (mostly removing the "nojail" keyword)/ I do not think this will cause problems, but it has been a fairly large volume of changes. Email me if you see problems that you think might be related to these changes. rick From nobody Sun Feb 19 00:33:36 2023 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 4PK63l4V4pz3s7yJ for ; Sun, 19 Feb 2023 00:33:39 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (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 "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4PK63k3hDLz3yvZ for ; Sun, 19 Feb 2023 00:33:38 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Authentication-Results: mx1.freebsd.org; dkim=none; spf=none (mx1.freebsd.org: domain of sgk@troutmask.apl.washington.edu has no SPF policy when checking 128.95.76.21) smtp.mailfrom=sgk@troutmask.apl.washington.edu; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=washington.edu (policy=none) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.17.1/8.17.1) with ESMTPS id 31J0XaDS089911 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Sat, 18 Feb 2023 16:33:36 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.17.1/8.17.1/Submit) id 31J0XaPY089910 for freebsd-current@freebsd.org; Sat, 18 Feb 2023 16:33:36 -0800 (PST) (envelope-from sgk) Date: Sat, 18 Feb 2023 16:33:36 -0800 From: Steve Kargl To: freebsd-current@freebsd.org Subject: core dump in ld during buildworld Message-ID: Reply-To: sgk@troutmask.apl.washington.edu 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 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable X-Spamd-Result: default: False [-2.90 / 15.00]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-0.999]; NEURAL_HAM_LONG(-0.90)[-0.897]; DMARC_POLICY_SOFTFAIL(0.10)[washington.edu : No valid SPF, No valid DKIM,none]; MIME_GOOD(-0.10)[text/plain]; FROM_EQ_ENVFROM(0.00)[]; R_SPF_NA(0.00)[no SPF record]; RCVD_TLS_LAST(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; ASN(0.00)[asn:73, ipnet:128.95.0.0/16, country:US]; RCVD_COUNT_THREE(0.00)[3]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; TO_DN_NONE(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; REPLYTO_ADDR_EQ_FROM(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; HAS_REPLYTO(0.00)[sgk@troutmask.apl.washington.edu] X-Rspamd-Queue-Id: 4PK63k3hDLz3yvZ X-Spamd-Bar: -- X-ThisMailContainsUnwantedMimeParts: N During biuldworld,=20 =3D=3D> usr.bin/nm (obj,all,install) cc -O2 -pipe -g -fno-common -I/usr/src/contrib/elftoolchain/libelftc -I/usr= /src/contrib/elftoolchain/common -std=3Dgnu99 -Wno-format-zero-length -Wsys= tem-headers -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototy= pes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-= strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts= -Wnested-externs -Wold-style-definition -Wno-pointer-sign -Wdate-time -Wmi= ssing-variable-declarations -Wthread-safety -Wno-empty-body -Wno-string-plu= s-int -Wno-unused-const-variable -Wno-error=3Dunused-but-set-variable -Qunu= sed-arguments -I/usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/include -Wl,-z= relro -static -L/usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/lib -o nm nm.= o -L/usr/obj/usr/src/amd64.amd64/tmp/obj-tools/lib/libdwarf -ldwarf -L/usr= /obj/usr/src/amd64.amd64/tmp/obj-tools/lib/libelf -lelf -L/usr/obj/usr/src/= amd64.amd64/tmp/obj-tools/lib/libz -lz -L/usr/obj/usr/src/amd64.amd64/tmp/o= bj-tools/lib/libelftc -lelftc_pie -L/usr/obj/usr/src/amd64.amd64/tmp/obj-to= ols/lib/libelf -lelf -legacy PLEASE submit a bug report to https://bugs.freebsd.org/submit/ and include = the crash backtrace. Stack dump: 0. Program arguments: /usr/bin/ld --eh-frame-hdr -Bstatic -o nm /usr/l= ib/crt1.o /usr/lib/crti.o /usr/lib/crtbeginT.o -L/usr/obj/usr/src/amd64.amd= 64/tmp/legacy/usr/lib -L/usr/obj/usr/src/amd64.amd64/tmp/obj-tools/lib/libd= warf -L/usr/obj/usr/src/amd64.amd64/tmp/obj-tools/lib/libelf -L/usr/obj/usr= /src/amd64.amd64/tmp/obj-tools/lib/libz -L/usr/obj/usr/src/amd64.amd64/tmp/= obj-tools/lib/libelftc -L/usr/obj/usr/src/amd64.amd64/tmp/obj-tools/lib/lib= elf -L/usr/lib -zrelro nm.o -ldwarf -lelf -lz -lelftc_pie -lelf -legacy -lg= cc -lgcc_eh -lc -lgcc -lgcc_eh /usr/lib/crtend.o /usr/lib/crtn.o #0 0x000000000164f1c1 (/usr/bin/ld+0x164f1c1) #1 0x000000000164d4a5 (/usr/bin/ld+0x164d4a5) #2 0x000000000164f8e0 (/usr/bin/ld+0x164f8e0) #3 0x0000000825243a60 (/lib/libthr.so.3+0x19a60) #4 0x000000082524301f (/lib/libthr.so.3+0x1901f) #5 0x00000008231e48a3 ([vdso]+0x2d3) #6 0x0000000000cf4830 (/usr/bin/ld+0xcf4830) #7 0x0000000000cf7b89 (/usr/bin/ld+0xcf7b89) #8 0x0000000000cf55a3 (/usr/bin/ld+0xcf55a3) #9 0x0000000000cf5217 (/usr/bin/ld+0xcf5217) #10 0x0000000000dabe23 (/usr/bin/ld+0xdabe23) #11 0x0000000000da7754 (/usr/bin/ld+0xda7754) #12 0x0000000000cf4ec5 (/usr/bin/ld+0xcf4ec5) #13 0x0000000000cc6e83 (/usr/bin/ld+0xcc6e83) #14 0x0000000000cbe4bc (/usr/bin/ld+0xcbe4bc) #15 0x0000000000cbccda (/usr/bin/ld+0xcbccda) cc: error: unable to execute command: Segmentation fault (core dumped) cc: error: linker command failed due to signal (use -v to see invocation) *** Error code 254 Stop. make[3]: stopped in /usr/src/usr.bin/nm *** Error code 1 % find /usr/obj/ -name \*.core /usr/obj/usr/src/amd64.amd64/tmp/obj-tools/usr.bin/nm/ld.lld.core % uname -a FreeBSD hotrats 14.0-CURRENT FreeBSD 14.0-CURRENT #0 main-n260094-906c312bb= f74: Fri Feb 3 21:28:39 PST 2023 kargl@hotrats:/usr/obj/usr/src/amd64.= amd64/sys/HOTRATS amd64 Is the wrong ld being called? The failing command shows /usr/bin/ld. Should this be /usr/obj/usr/src/amd64.amd64/tmp/usr/bin/ld? --=20 Steve From nobody Sun Feb 19 00:50:07 2023 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 4PK6R51Vwjz3s8vm for ; Sun, 19 Feb 2023 00:50:25 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4PK6R510l0z44TT; Sun, 19 Feb 2023 00:50:25 +0000 (UTC) (envelope-from dim@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1676767825; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=WMXqKg1b/9Na1IENIfpFzAfDxCf4O6iIfVDJb2cosIY=; b=jYhIeuyKveldnS/BvnimrV278HYXEKhEfVxbFtjdT99xyH/6telor0+zOpd6zPI4xaYs7U 80Hx3NZizLSNPI0Woq74MCL15+AsQlPsQVLQHnkfOkgakZekwd+9G3MO/3/IJ4J8DKB0LC F27VDPUD5gE5UJL2Z5X2AzoAdUNsBJU23+1gnJyNnNaet/txZ2WkOCMHvVNgJ115uwiHIi fBWJGhd8iIDc23+DJpSXRE1FwtkgQ84Q1flcfuoh0gfCHaKtah0hwT0kckQoaUcKUa5im3 ptB9JeIex03ighAqLxC7tuqQK98f2RLqM57xSyLVyN+36TGBnR+pXyZ3U+OnKg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1676767825; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=WMXqKg1b/9Na1IENIfpFzAfDxCf4O6iIfVDJb2cosIY=; b=H8gY7f24BJ5pyh+sasXIcowefkuD6GM3pp46w+v4Po/+OYmjT1gBInDcg3FvNnyU8+kLqn jgysLcdkYsbvi5Muon6XYsdfHsDWcp6LcC/L90vfjQrPdjL9lvzruHYlk/qduPkNVnR/6N ML+rG6w8r4GxErass8jPoU12URQ6AENtCXXOSNvsZsMqlvKNFI3EG9NZYCiDQOXXnwfPJE DcbK/67SbIvcXPi4xdKRxalI162AlyZleSN9k4Ix81Kqb14d10S7vKtli7+WSM7fTA/XF5 fhStWdGhehT7BHMaC3OqRKC8rT1f4qMornPAnbZIbvDKHj+jAZf3hBTqiQ4tjw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1676767825; a=rsa-sha256; cv=none; b=udsOGSH+YZ4AOszCwjF9gYK8owEzqnxAWT3YxXq4leSxQFgQopIx5PzrguoOTwE+4M5S04 59JfK4TiKA+Ky6mwQyBkOCsWIB4kbKKWOIPH4HQmc0DnaNK7tgQrQnBy2TgdhI2YXEz/Vb rKZHcTOhuS3R3AtI8z91DpNsITER4v/aqn1fV4Et0mTiaKBpeWsxKnIPb6fFl6qpgbPfxW rzQ35NaLyHNrADzGixRqraCVo5/iTXW72ZibiH9qY6OupH9D5y9L6NY8CXaCfEqzAydELZ CuLLHtXn3u/38FQGwhLIIM7W6lWSFYoY1ZLX4C4xwFzbmZH+rchqdu39uKPGGg== Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) (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 "tensor.andric.com", Issuer "R3" (verified OK)) (Authenticated sender: dim) by smtp.freebsd.org (Postfix) with ESMTPSA id 4PK6R46RH1zPsJ; Sun, 19 Feb 2023 00:50:24 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from smtpclient.apple (longrow.home.andric.com [192.168.0.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 44F9A216DF; Sun, 19 Feb 2023 01:50:23 +0100 (CET) Content-Type: multipart/signed; boundary="Apple-Mail=_A7E4265B-CB90-49F7-ABED-E40FD401FE93"; protocol="application/pgp-signature"; micalg=pgp-sha1 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 Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.400.51.1.1\)) Subject: Re: core dump in ld during buildworld From: Dimitry Andric In-Reply-To: Date: Sun, 19 Feb 2023 01:50:07 +0100 Cc: freebsd-current@freebsd.org Message-Id: <25B4B3AD-3791-44D0-9FFA-7F1C2A9E82B9@FreeBSD.org> References: To: sgk@troutmask.apl.washington.edu X-Mailer: Apple Mail (2.3731.400.51.1.1) X-ThisMailContainsUnwantedMimeParts: N --Apple-Mail=_A7E4265B-CB90-49F7-ABED-E40FD401FE93 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 19 Feb 2023, at 01:33, Steve Kargl = wrote: >=20 > During biuldworld, >=20 > =3D=3D> usr.bin/nm (obj,all,install) > cc -O2 -pipe -g -fno-common -I/usr/src/contrib/elftoolchain/libelftc = -I/usr/src/contrib/elftoolchain/common -std=3Dgnu99 = -Wno-format-zero-length -Wsystem-headers -Wall -Wno-format-y2k -W = -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes = -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch = -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts = -Wnested-externs -Wold-style-definition -Wno-pointer-sign -Wdate-time = -Wmissing-variable-declarations -Wthread-safety -Wno-empty-body = -Wno-string-plus-int -Wno-unused-const-variable = -Wno-error=3Dunused-but-set-variable -Qunused-arguments = -I/usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/include -Wl,-zrelro = -static -L/usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/lib -o nm nm.o = -L/usr/obj/usr/src/amd64.amd64/tmp/obj-tools/lib/libdwarf -ldwarf = -L/usr/obj/usr/src/amd64.amd64/tmp/obj-tools/lib/libelf -lelf = -L/usr/obj/usr/src/amd64.amd64/tmp/obj-tools/lib/libz -lz = -L/usr/obj/usr/src/amd64.amd64/tmp/obj-tools/lib/libelftc -lelftc_pie = -L/usr/obj/usr/src/amd64.amd64/tmp/obj-tools/lib/libelf -lelf -legacy > PLEASE submit a bug report to https://bugs.freebsd.org/submit/ and = include the crash backtrace. > Stack dump: > 0. Program arguments: /usr/bin/ld --eh-frame-hdr -Bstatic -o nm = /usr/lib/crt1.o /usr/lib/crti.o /usr/lib/crtbeginT.o = -L/usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/lib = -L/usr/obj/usr/src/amd64.amd64/tmp/obj-tools/lib/libdwarf = -L/usr/obj/usr/src/amd64.amd64/tmp/obj-tools/lib/libelf = -L/usr/obj/usr/src/amd64.amd64/tmp/obj-tools/lib/libz = -L/usr/obj/usr/src/amd64.amd64/tmp/obj-tools/lib/libelftc = -L/usr/obj/usr/src/amd64.amd64/tmp/obj-tools/lib/libelf -L/usr/lib = -zrelro nm.o -ldwarf -lelf -lz -lelftc_pie -lelf -legacy -lgcc -lgcc_eh = -lc -lgcc -lgcc_eh /usr/lib/crtend.o /usr/lib/crtn.o > #0 0x000000000164f1c1 (/usr/bin/ld+0x164f1c1) > #1 0x000000000164d4a5 (/usr/bin/ld+0x164d4a5) > #2 0x000000000164f8e0 (/usr/bin/ld+0x164f8e0) > #3 0x0000000825243a60 (/lib/libthr.so.3+0x19a60) > #4 0x000000082524301f (/lib/libthr.so.3+0x1901f) > #5 0x00000008231e48a3 ([vdso]+0x2d3) > #6 0x0000000000cf4830 (/usr/bin/ld+0xcf4830) > #7 0x0000000000cf7b89 (/usr/bin/ld+0xcf7b89) > #8 0x0000000000cf55a3 (/usr/bin/ld+0xcf55a3) > #9 0x0000000000cf5217 (/usr/bin/ld+0xcf5217) > #10 0x0000000000dabe23 (/usr/bin/ld+0xdabe23) > #11 0x0000000000da7754 (/usr/bin/ld+0xda7754) > #12 0x0000000000cf4ec5 (/usr/bin/ld+0xcf4ec5) > #13 0x0000000000cc6e83 (/usr/bin/ld+0xcc6e83) > #14 0x0000000000cbe4bc (/usr/bin/ld+0xcbe4bc) > #15 0x0000000000cbccda (/usr/bin/ld+0xcbccda) > cc: error: unable to execute command: Segmentation fault (core dumped) > cc: error: linker command failed due to signal (use -v to see = invocation) > *** Error code 254 >=20 > Stop. > make[3]: stopped in /usr/src/usr.bin/nm > *** Error code 1 >=20 > % find /usr/obj/ -name \*.core > /usr/obj/usr/src/amd64.amd64/tmp/obj-tools/usr.bin/nm/ld.lld.core > % uname -a > FreeBSD hotrats 14.0-CURRENT FreeBSD 14.0-CURRENT #0 = main-n260094-906c312bbf74: Fri Feb 3 21:28:39 PST 2023 = kargl@hotrats:/usr/obj/usr/src/amd64.amd64/sys/HOTRATS amd64 >=20 > Is the wrong ld being called? The failing command shows /usr/bin/ld. > Should this be /usr/obj/usr/src/amd64.amd64/tmp/usr/bin/ld? It looks like this happens during the early stages, most likely cross-tools? (As it appears to be building usr.bin/nm under obj-tools.) At that point it is still using the system compiler and linker, and it seems that the latter is lld. Do you know which version it is? -Dimitry --Apple-Mail=_A7E4265B-CB90-49F7-ABED-E40FD401FE93 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----- Version: GnuPG/MacGPG2 v2.2 iF0EARECAB0WIQR6tGLSzjX8bUI5T82wXqMKLiCWowUCY/FyPwAKCRCwXqMKLiCW o5ulAJ4hQFq7InjIU414xXh2ALqJz78dnQCfcs2YrclNeZE4HZqO0X1rMTv9obk= =xhTA -----END PGP SIGNATURE----- --Apple-Mail=_A7E4265B-CB90-49F7-ABED-E40FD401FE93-- From nobody Sun Feb 19 00:57:45 2023 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 4PK6bb5vFcz3s9K9 for ; Sun, 19 Feb 2023 00:57:47 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (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 "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4PK6bb4Fpfz461J; Sun, 19 Feb 2023 00:57:47 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Authentication-Results: mx1.freebsd.org; none Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.17.1/8.17.1) with ESMTPS id 31J0vjqg090024 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Sat, 18 Feb 2023 16:57:46 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.17.1/8.17.1/Submit) id 31J0vjcb090023; Sat, 18 Feb 2023 16:57:45 -0800 (PST) (envelope-from sgk) Date: Sat, 18 Feb 2023 16:57:45 -0800 From: Steve Kargl To: Dimitry Andric Cc: freebsd-current@freebsd.org Subject: Re: core dump in ld during buildworld Message-ID: Reply-To: sgk@troutmask.apl.washington.edu References: <25B4B3AD-3791-44D0-9FFA-7F1C2A9E82B9@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 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: <25B4B3AD-3791-44D0-9FFA-7F1C2A9E82B9@FreeBSD.org> X-Rspamd-Queue-Id: 4PK6bb4Fpfz461J X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:73, ipnet:128.95.0.0/16, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N On Sun, Feb 19, 2023 at 01:50:07AM +0100, Dimitry Andric wrote: > On 19 Feb 2023, at 01:33, Steve Kargl = wrote: > >=20 > > During biuldworld, > >=20 > > =3D=3D> usr.bin/nm (obj,all,install) > > cc -O2 -pipe -g -fno-common -I/usr/src/contrib/elftoolchain/libelftc -I= /usr/src/contrib/elftoolchain/common -std=3Dgnu99 -Wno-format-zero-length -= Wsystem-headers -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-pro= totypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwr= ite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscr= ipts -Wnested-externs -Wold-style-definition -Wno-pointer-sign -Wdate-time = -Wmissing-variable-declarations -Wthread-safety -Wno-empty-body -Wno-string= -plus-int -Wno-unused-const-variable -Wno-error=3Dunused-but-set-variable -= Qunused-arguments -I/usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/include -W= l,-zrelro -static -L/usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/lib -o nm= nm.o -L/usr/obj/usr/src/amd64.amd64/tmp/obj-tools/lib/libdwarf -ldwarf -L= /usr/obj/usr/src/amd64.amd64/tmp/obj-tools/lib/libelf -lelf -L/usr/obj/usr/= src/amd64.amd64/tmp/obj-tools/lib/libz -lz -L/usr/obj/usr/src/amd64.amd64/t= mp/obj-tools/lib/libelftc -lelftc_pie -L/usr/obj/usr/src/amd64.amd64/tmp/ob= j-tools/lib/libelf -lelf -legacy > > PLEASE submit a bug report to https://bugs.freebsd.org/submit/ and incl= ude the crash backtrace. > > Stack dump: > > 0. Program arguments: /usr/bin/ld --eh-frame-hdr -Bstatic -o nm /u= sr/lib/crt1.o /usr/lib/crti.o /usr/lib/crtbeginT.o -L/usr/obj/usr/src/amd64= =2Eamd64/tmp/legacy/usr/lib -L/usr/obj/usr/src/amd64.amd64/tmp/obj-tools/li= b/libdwarf -L/usr/obj/usr/src/amd64.amd64/tmp/obj-tools/lib/libelf -L/usr/o= bj/usr/src/amd64.amd64/tmp/obj-tools/lib/libz -L/usr/obj/usr/src/amd64.amd6= 4/tmp/obj-tools/lib/libelftc -L/usr/obj/usr/src/amd64.amd64/tmp/obj-tools/l= ib/libelf -L/usr/lib -zrelro nm.o -ldwarf -lelf -lz -lelftc_pie -lelf -lega= cy -lgcc -lgcc_eh -lc -lgcc -lgcc_eh /usr/lib/crtend.o /usr/lib/crtn.o > > #0 0x000000000164f1c1 (/usr/bin/ld+0x164f1c1) > > #1 0x000000000164d4a5 (/usr/bin/ld+0x164d4a5) > > #2 0x000000000164f8e0 (/usr/bin/ld+0x164f8e0) > > #3 0x0000000825243a60 (/lib/libthr.so.3+0x19a60) > > #4 0x000000082524301f (/lib/libthr.so.3+0x1901f) > > #5 0x00000008231e48a3 ([vdso]+0x2d3) > > #6 0x0000000000cf4830 (/usr/bin/ld+0xcf4830) > > #7 0x0000000000cf7b89 (/usr/bin/ld+0xcf7b89) > > #8 0x0000000000cf55a3 (/usr/bin/ld+0xcf55a3) > > #9 0x0000000000cf5217 (/usr/bin/ld+0xcf5217) > > #10 0x0000000000dabe23 (/usr/bin/ld+0xdabe23) > > #11 0x0000000000da7754 (/usr/bin/ld+0xda7754) > > #12 0x0000000000cf4ec5 (/usr/bin/ld+0xcf4ec5) > > #13 0x0000000000cc6e83 (/usr/bin/ld+0xcc6e83) > > #14 0x0000000000cbe4bc (/usr/bin/ld+0xcbe4bc) > > #15 0x0000000000cbccda (/usr/bin/ld+0xcbccda) > > cc: error: unable to execute command: Segmentation fault (core dumped) > > cc: error: linker command failed due to signal (use -v to see invocatio= n) > > *** Error code 254 > >=20 > > Stop. > > make[3]: stopped in /usr/src/usr.bin/nm > > *** Error code 1 > >=20 > > % find /usr/obj/ -name \*.core > > /usr/obj/usr/src/amd64.amd64/tmp/obj-tools/usr.bin/nm/ld.lld.core > > % uname -a > > FreeBSD hotrats 14.0-CURRENT FreeBSD 14.0-CURRENT #0 main-n260094-906c3= 12bbf74: Fri Feb 3 21:28:39 PST 2023 kargl@hotrats:/usr/obj/usr/src/am= d64.amd64/sys/HOTRATS amd64 > >=20 > > Is the wrong ld being called? The failing command shows /usr/bin/ld. > > Should this be /usr/obj/usr/src/amd64.amd64/tmp/usr/bin/ld? >=20 > It looks like this happens during the early stages, most likely > cross-tools? (As it appears to be building usr.bin/nm under obj-tools.) >=20 > At that point it is still using the system compiler and linker, and it > seems that the latter is lld. Do you know which version it is? >=20 Good question. Unfortunate ident(1) is useless in a git world. % ll /usr/bin/ld.lld -r-xr-xr-x 1 root wheel - 41754432 Jan 15 12:03 /usr/bin/ld.lld This was built from source from Jan 15 2023.=20 % /usr/bin/ld.lld --version LLD 14.0.5 (FreeBSD llvmorg-14.0.5-0-gc12386ae247c-1400004) (compatible wit= h GNU linkers) =20 --=20 Steve From nobody Sun Feb 19 04:35:01 2023 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 4PKCRW5QRWz3sggV for ; Sun, 19 Feb 2023 04:36:07 +0000 (UTC) (envelope-from sjg@juniper.net) Received: from mx0b-00273201.pphosted.com (mx0b-00273201.pphosted.com [67.231.152.164]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.pphosted.com", Issuer "Thawte RSA CA 2018" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4PKCRV3vpnz3CmX; Sun, 19 Feb 2023 04:36:06 +0000 (UTC) (envelope-from sjg@juniper.net) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=juniper.net header.s=PPS1017 header.b=k9QCl8NL; dkim=pass header.d=juniper.net header.s=selector1 header.b=RmCy388l; spf=pass (mx1.freebsd.org: domain of sjg@juniper.net designates 67.231.152.164 as permitted sender) smtp.mailfrom=sjg@juniper.net; dmarc=pass (policy=reject) header.from=juniper.net; arc=pass ("microsoft.com:s=arcselector9901:i=1") Received: from pps.filterd (m0108161.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 31J4AGaD007242; Sat, 18 Feb 2023 20:36:01 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=to : cc : subject : in-reply-to : references : from : mime-version : content-type : content-transfer-encoding : date : message-id; s=PPS1017; bh=PXDGExweYZLmP/5bq6bRGC7aCAheIZJhCv5Lrwxk8xY=; b=k9QCl8NLAUtYOs5eq6MTHLK8/n/lryVd2mejINJuYU8O9kxRGak4B/5WWtb7Jf6rf1Ra HoxTPcMj0SEvMe5SFBWVq8sAJo/lp+cXIt3wKhJ2+73YLrzxxNlFnPfMcNlijr/netcW OEi2/OIF5SczajlnZpMqrEQF7QhtrZWqlJ/j5UWsf5JBiz/peCZnzEzh5cSd2MhqsVpo f+fAZvDUx82KEXSf/EpuqjwLS5+fOqy68C1kGEP4UyEPZ4YNDSeJC0lQHE2GHkg+pIna BzL7qVBnaljXxk5zCkNY5YhXW1DWB8xnNvvgTtmueVkrqpg33xko8U3TObvweSFxpyjE RQ== Received: from cy4pr02cu007-vft-obe.outbound.protection.outlook.com (mail-westcentralusazlp17011017.outbound.protection.outlook.com [40.93.6.17]) by mx0b-00273201.pphosted.com (PPS) with ESMTPS id 3ntxp30tu2-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 18 Feb 2023 20:36:01 -0800 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=dpF0Z7zQUEEjlUooVYe8Dk6sDYiZtFdhMJ5HMBPKhe1RGGxZKC4GzT0/l1FFunqRPG30HkRuoPQO9ai8beRBJ6FXdGAYw2RqucsWd89gBWZE+Xf6mYxP20o3+9WzX9mGL0uoCO12tWN0zrwSiLWN5vkefkhq06HFBxRCvNN8kNkg28+l0WJM/gCPYT1VRajN0xKD1ZPP7WiU8ZM1kYU7JHrxWVLgjE//JyYFlS8rVpaUt8SRv1Ncjbm/njlZo9Td93x7Cv4ZWZ9p8biqpJYu6DJDH89xM8/HONpqjr50Q8KEhtt30lXCt55d7lntZErGnYg7abCiVBnEB5M8rOwcRA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=PXDGExweYZLmP/5bq6bRGC7aCAheIZJhCv5Lrwxk8xY=; b=dP59NzP4Edy9NtkG0Gk2RcPnq3cZg99J3yF791W06EJbcWJoDX5av6wXs7krrV+QqdtovJLYSM6QPIWyXEoVf9CgBhSvQ+ptQbA+lw0R3qGjAteLCqGfAA91tT9gZSZWFye3mP+0fD5XuuC1fygnlw+U0pzRPldYMpKeICwdd7QYIjqTSRhVdY7XI417D1ldRuFsvn24wA7HtE5Lzn3xrJ9KDRS193qTrSeXpY+9k+1oYrwzRYC7nrurDrEOVvHxm2nrv1i5dupfXlqf83VCKm4o1Wg936bZJUJy0XPRVoOI6l5k9dNyEx7C40bdsz2fx7uHJ0BBCuBn995E/HhKSQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=softfail (sender ip is 66.129.239.15) smtp.rcpttodomain=igalic.co smtp.mailfrom=juniper.net; dmarc=fail (p=reject sp=reject pct=100) action=oreject header.from=juniper.net; dkim=none (message not signed); arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=PXDGExweYZLmP/5bq6bRGC7aCAheIZJhCv5Lrwxk8xY=; b=RmCy388lVcLHW5VclWtcjn1d8oI3vkeZX95aQe5wsw/x7a+sNv0kQKf6/I8k662Q6+f3V9V/5BkQhQSA6AnLL8e3oFw6KqzGN+CG/Ga+hFOBoSUyUWG3zIQvAX+TZybl/y7cx6/7ikhPxuAYVA6eKhkWBf4D9mWL54WM1YifBSI= Received: from DM6PR07CA0090.namprd07.prod.outlook.com (2603:10b6:5:337::23) by DM6PR05MB5417.namprd05.prod.outlook.com (2603:10b6:5:a::32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6111.15; Sun, 19 Feb 2023 04:35:56 +0000 Received: from DM6NAM12FT061.eop-nam12.prod.protection.outlook.com (2603:10b6:5:337:cafe::15) by DM6PR07CA0090.outlook.office365.com (2603:10b6:5:337::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6111.18 via Frontend Transport; Sun, 19 Feb 2023 04:35:56 +0000 X-MS-Exchange-Authentication-Results: spf=softfail (sender IP is 66.129.239.15) smtp.mailfrom=juniper.net; dkim=none (message not signed) header.d=none;dmarc=fail action=oreject header.from=juniper.net; Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.15 as permitted sender) Received: from p-exchfe-eqx-02.jnpr.net (66.129.239.15) by DM6NAM12FT061.mail.protection.outlook.com (10.13.179.123) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6134.14 via Frontend Transport; Sun, 19 Feb 2023 04:35:56 +0000 Received: from p-exchbe-eqx-02.jnpr.net (10.104.9.15) by p-exchfe-eqx-02.jnpr.net (10.104.9.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.30; Sat, 18 Feb 2023 22:35:56 -0600 Received: from p-mailhub01.juniper.net (10.104.20.6) by p-exchbe-eqx-02.jnpr.net (10.104.9.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.30 via Frontend Transport; Sat, 18 Feb 2023 22:35:55 -0600 Received: from kaos.jnpr.net (kaos.jnpr.net [172.23.255.201]) by p-mailhub01.juniper.net (8.14.4/8.11.3) with ESMTP id 31J4ZstQ010593; Sat, 18 Feb 2023 20:35:55 -0800 (envelope-from sjg@juniper.net) Received: by kaos.jnpr.net (Postfix, from userid 1377) id 479441F841; Sat, 18 Feb 2023 20:35:01 -0800 (PST) Received: from kaos.jnpr.net (localhost [127.0.0.1]) by kaos.jnpr.net (Postfix) with ESMTP id 43E8F1FA1B; Sat, 18 Feb 2023 20:35:01 -0800 (PST) To: Warner Losh CC: =?us-ascii?Q?=3D=3FUTF-8=3FQ=3FMina=5FGali=3DC4=3D87=3F=3D?= , Gordon Bergling , FreeBSD Current , Subject: Re: Build breakage with WITH_BEARSSL=1 In-Reply-To: References: Comments: In-reply-to: Warner Losh message dated "Wed, 15 Feb 2023 13:28:12 -0700." From: "Simon J. Gerraty" X-Mailer: MH-E 8.6+git; nmh 1.7.1; GNU Emacs 28.1 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 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Date: Sat, 18 Feb 2023 20:35:01 -0800 Message-ID: <58627.1676781301@kaos.jnpr.net> X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: DM6NAM12FT061:EE_|DM6PR05MB5417:EE_ X-MS-Office365-Filtering-Correlation-Id: 666b29b8-1305-4b55-a221-08db1232cb01 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: VcN+fVKi6sUURuS6SFmclLZcxsQhZ0sahPH5w3QBHhpExNnGgtPu8HM8ELl5FhNQ4H3zucMOJTXAjd2fwEt3wpriX92Flgmr1mbD8gbuCHB1GWTR2f9cnj7jwtV1lez5BzmE8qf4DvlHFmMRS9CKW5tYSkUsGZWEsPqsVEahUmqhd3LyJKrVI4p75imoW/kO91L29FCuGjMe5YiCIYFVSzsaYVum+E0A6XvPo15flOI8Ymn7ehiVKiY1c/urWMMimwytLqrP5G1sdiuCklb3tjaHzgdQ5pqIcQiMzAUwwowaqR4LVZW6iU6lMulDzKPL9Y4nM05/3qyboP9cXaTVKqvUYl0sM3afBmuFRk1QATkOLxVkJJK87CMC4urBFlxCn5w1/gKwk8cvEbsxeAsmaVKBhKAiszL3/OimcH3zc68k5BZtB55MiVivxJdUHiJYccfz13clErslcCtQI/xrav7IZ2PGrS5CnDZMxN1Jhx52paM36tBmtMVFoaYl7sr2bQNMg6ntMS8qEYj6nKVrboQeb55JRSI17NCPzA03VIYFdIa59rQvP1t0/cAbK3dJqyrk8gkHCVh0g0FDOP/vei/Vwy2AGu8Is9iTuWWJMdP53rBzNU/JLTCnBjiQn5vkPo6QJoLX9T9x+wDKiBn81phas877/wt9fWl3UIWkNR1X7Pcq/Z0Gn9dxzOWgBzQlb1/i37H2mKtlC1SBLr83IdciLPohImPYX5aeRVGPMGQMoRIjbeSAt5KgUISbW/6cwOVch214sgcX/ldk9LpzXHt1oxXECtwfdfGghvk6vVA= X-Forefront-Antispam-Report: CIP:66.129.239.15;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:p-exchfe-eqx-02.jnpr.net;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230025)(4636009)(376002)(396003)(346002)(136003)(39860400002)(451199018)(40470700004)(36840700001)(46966006)(107886003)(186003)(356005)(55016003)(8936002)(2906002)(6266002)(26005)(82740400003)(9686003)(47076005)(81166007)(316002)(4744005)(478600001)(40460700003)(36860700001)(40480700001)(336012)(41300700001)(7126003)(5660300002)(86362001)(8676002)(70586007)(4326008)(82310400005)(70206006)(54906003)(6916009)(7696005)(36900700001);DIR:OUT;SFP:1102; X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 Feb 2023 04:35:56.5666 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 666b29b8-1305-4b55-a221-08db1232cb01 X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4;Ip=[66.129.239.15];Helo=[p-exchfe-eqx-02.jnpr.net] X-MS-Exchange-CrossTenant-AuthSource: DM6NAM12FT061.eop-nam12.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR05MB5417 X-Proofpoint-GUID: 1vg6vPgTknO6eYjD3CqqU-gGenPY9Dqb X-Proofpoint-ORIG-GUID: 1vg6vPgTknO6eYjD3CqqU-gGenPY9Dqb X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.219,Aquarius:18.0.930,Hydra:6.0.562,FMLib:17.11.170.22 definitions=2023-02-19_01,2023-02-17_01,2023-02-09_01 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 bulkscore=0 phishscore=0 impostorscore=0 lowpriorityscore=0 clxscore=1011 mlxscore=0 malwarescore=0 spamscore=0 adultscore=0 priorityscore=1501 mlxlogscore=350 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2212070000 definitions=main-2302190042 X-Spamd-Result: default: False [-3.90 / 15.00]; CC_EXCESS_QP(1.20)[]; ARC_ALLOW(-1.00)[microsoft.com:s=arcselector9901:i=1]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.999]; DMARC_POLICY_ALLOW(-0.50)[juniper.net,reject]; R_SPF_ALLOW(-0.20)[+ip4:67.231.152.164]; R_DKIM_ALLOW(-0.20)[juniper.net:s=PPS1017,juniper.net:s=selector1]; RCVD_IN_DNSWL_LOW(-0.10)[67.231.152.164:from]; MIME_GOOD(-0.10)[text/plain]; FROM_EQ_ENVFROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:22843, ipnet:67.231.152.0/24, country:US]; RCVD_TLS_LAST(0.00)[]; TO_DN_SOME(0.00)[]; FREEFALL_USER(0.00)[sjg]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_FIVE(0.00)[5]; RCVD_IN_DNSWL_NONE(0.00)[40.93.6.17:received]; RCVD_COUNT_SEVEN(0.00)[11]; DKIM_TRACE(0.00)[juniper.net:+]; TO_MATCH_ENVRCPT_SOME(0.00)[] X-Rspamd-Queue-Id: 4PKCRV3vpnz3CmX X-Spamd-Bar: --- X-ThisMailContainsUnwantedMimeParts: N Warner Losh wrote: > Would be nice if we could get upstream to actually fix this, but i don't = even know how to submit bugs there=E2=80=A6 >=20 > Agreed. I didn't recall off of the top of my head, so I did the quick ban= daid. I can reach out to the author, I don't know that he has a bug tracker. What is the problem? lack of prototype declarations? From nobody Sun Feb 19 04:36:00 2023 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 4PKCSn6Dgzz3sh5B for ; Sun, 19 Feb 2023 04:37:13 +0000 (UTC) (envelope-from sjg@juniper.net) Received: from mx0b-00273201.pphosted.com (mx0b-00273201.pphosted.com [67.231.152.164]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.pphosted.com", Issuer "Thawte RSA CA 2018" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4PKCSm6j53z3Dvc; Sun, 19 Feb 2023 04:37:12 +0000 (UTC) (envelope-from sjg@juniper.net) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=juniper.net header.s=PPS1017 header.b="fN/ygY81"; dkim=pass header.d=juniper.net header.s=selector1 header.b=ed795oDt; spf=pass (mx1.freebsd.org: domain of sjg@juniper.net designates 67.231.152.164 as permitted sender) smtp.mailfrom=sjg@juniper.net; dmarc=pass (policy=reject) header.from=juniper.net; arc=pass ("microsoft.com:s=arcselector9901:i=1") Received: from pps.filterd (m0108161.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 31J4N53Q030795; Sat, 18 Feb 2023 20:37:12 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=to : cc : subject : in-reply-to : references : from : mime-version : content-type : content-id : date : message-id; s=PPS1017; bh=uo4yoAMVVhMykG1NPiltlYVDivDaCb2la/D7hJJ/MEI=; b=fN/ygY81rTrjfmQ+7QOH36R+AjEpXZZL9dVs2mrBhcU6TY3w6u9gKVm2Uijiz3SGh1lT jpcNW1dmCDZw0JrjQtqhazjmRT1vlRERrQqJtbQPVsukopGzYXhXZaAvCJH1UlD0nzXn GdoJi4dvWrijWnbWXvF5Z20onIm/Os5GfeA1RtnbpywL4U9WVMsmFjXVnPVdsPdrngIZ yXyNeWwcY3rW391b8hKQWL4JDxiAdTogkyTeOla7St0TEwnrJHiHI9EX+Cg6kAsVhcvy QSpvbYMdy/VcnzySF0y0uzycPWRR/emmVkyQrBHdhw0HpnbX7hK5u5GTJSjOBuX3wrmY 3Q== Received: from co1pr02cu001-vft-obe.outbound.protection.outlook.com (mail-westus2azlp17011011.outbound.protection.outlook.com [40.93.10.11]) by mx0b-00273201.pphosted.com (PPS) with ESMTPS id 3ntxp30tv4-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 18 Feb 2023 20:37:11 -0800 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=P0pHz6XEbYxoQzyz4tcx5xdSrman6pkWaByxTmfeTWt0R9qPNYYo8jBodSTQT+qM4ChabPxm+98lupBfLRcUuKKDmosRxJVBnTHBC8FDZfdIvrYXrptmsDi0K2MTElYTrbghalOdkJhZLW3XQPPSUbZdsYIinUQVm1vspSL91CgrkNYmFC+zRKNdBYB7RP9nVdFDToOsO+zyO/kNDSK0A/G3NOyqzN9udJibrYg8KRAp9kEjVG3iQWl42a9YboLchK90dYG30O6xPtEiTVjECZOt79+XQwSsle73qQ3hSBhZQso4WODhbcdf3CAoQFfhgHEttpoidISKtPupjOBZmg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=uo4yoAMVVhMykG1NPiltlYVDivDaCb2la/D7hJJ/MEI=; b=QB5NMBXCCxB6HOC5QloBiujmqJZofc++McHBYFy6bZrhG870n4m2Bdj9SlwF9qOvTHMVtSRgzjZWx3CyIAI4/SUiAX4DAoJXzuLPj/NRXeegnkyVvQn3L9BF8lNQwa1YiC6S9RA9KkuPWps4aIkALGZU3OUQiwyaEObHcXYJ7SUqWt4vsKVCWHGBKRcyhTbWKn+2si9vMYp41xpEFXbzDUkipRWwEnQUyEjUZ59SDmzUJgwwSeWjQnR1ubWGw9LcmLiZoULxXsdeBZk6LE6ebZzxG8kMcKpqOOziMjaWDMdH4eiznR402MlVLesZZBfZKqJmGHL1TZgUWS17SJ/8EA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=softfail (sender ip is 66.129.239.15) smtp.rcpttodomain=stormshield.eu smtp.mailfrom=juniper.net; dmarc=fail (p=reject sp=reject pct=100) action=oreject header.from=juniper.net; dkim=none (message not signed); arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=uo4yoAMVVhMykG1NPiltlYVDivDaCb2la/D7hJJ/MEI=; b=ed795oDtDpF7QfXxVgGGmPoUtX7Qrbbk153fbHfJ62L54keqz/0Le17Ch4MC1AHLdNMLKY8EHBM2IhUTS3CibQwy6omL4Eli2r9VU2V/jWPVuExHe5dM8S2lB56FyOB6sBdrwsmeSXycnBC8ldhHwCDWkU4nOJJUf+3186UEh5o= Received: from DS7PR03CA0086.namprd03.prod.outlook.com (2603:10b6:5:3bb::31) by SJ0PR05MB7820.namprd05.prod.outlook.com (2603:10b6:a03:2ed::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6111.18; Sun, 19 Feb 2023 04:36:57 +0000 Received: from DM6NAM12FT092.eop-nam12.prod.protection.outlook.com (2603:10b6:5:3bb:cafe::35) by DS7PR03CA0086.outlook.office365.com (2603:10b6:5:3bb::31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6111.18 via Frontend Transport; Sun, 19 Feb 2023 04:36:56 +0000 X-MS-Exchange-Authentication-Results: spf=softfail (sender IP is 66.129.239.15) smtp.mailfrom=juniper.net; dkim=none (message not signed) header.d=none;dmarc=fail action=oreject header.from=juniper.net; Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.15 as permitted sender) Received: from p-exchfe-eqx-02.jnpr.net (66.129.239.15) by DM6NAM12FT092.mail.protection.outlook.com (10.13.179.140) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6134.14 via Frontend Transport; Sun, 19 Feb 2023 04:36:56 +0000 Received: from p-exchbe-eqx-02.jnpr.net (10.104.9.15) by p-exchfe-eqx-02.jnpr.net (10.104.9.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.30; Sat, 18 Feb 2023 22:36:55 -0600 Received: from p-exchbe-eqx-01.jnpr.net (10.104.9.14) by p-exchbe-eqx-02.jnpr.net (10.104.9.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.30; Sat, 18 Feb 2023 22:36:55 -0600 Received: from p-mailhub01.juniper.net (10.104.20.6) by p-exchbe-eqx-01.jnpr.net (10.104.9.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.30 via Frontend Transport; Sat, 18 Feb 2023 22:36:55 -0600 Received: from kaos.jnpr.net (kaos.jnpr.net [172.23.255.201]) by p-mailhub01.juniper.net (8.14.4/8.11.3) with ESMTP id 31J4as1L010730; Sat, 18 Feb 2023 20:36:54 -0800 (envelope-from sjg@juniper.net) Received: by kaos.jnpr.net (Postfix, from userid 1377) id EB1141F8C2; Sat, 18 Feb 2023 20:36:00 -0800 (PST) Received: from kaos.jnpr.net (localhost [127.0.0.1]) by kaos.jnpr.net (Postfix) with ESMTP id E945E1F926; Sat, 18 Feb 2023 20:36:00 -0800 (PST) To: Stephane Rochoy CC: , Mina =?utf-8?Q?Gali=C4=87?= , Gordon Bergling , Subject: Re: Build breakage with WITH_BEARSSL=1 In-Reply-To: <86mt5evwpr.fsf@cthulhu.stephaner.labo.int> References: <86mt5evwpr.fsf@cthulhu.stephaner.labo.int> Comments: In-reply-to: Stephane Rochoy message dated "Thu, 16 Feb 2023 09:30:24 +0100." From: "Simon J. Gerraty" X-Mailer: MH-E 8.6+git; nmh 1.7.1; GNU Emacs 28.1 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 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <20025.1676781360.1@kaos.jnpr.net> Date: Sat, 18 Feb 2023 20:36:00 -0800 Message-ID: <24630.1676781360@kaos.jnpr.net> X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: DM6NAM12FT092:EE_|SJ0PR05MB7820:EE_ X-MS-Office365-Filtering-Correlation-Id: e1de816d-5379-4fa0-90b6-08db1232eeb7 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: BKc1Oty3gWoSNarnfSPdrXOS/7LmbErgW+Lo4YcuQyZq3iwwwHHxWtcBj9rJ2kkKKQinbUlC7YIDhifl05nMz1Vco8b8RlYKYLWV7drPu+1rrTLEktgBO0F1TzehkwFmRi2TILHuLMfK2iDq7MChK9ugIjAbeDzl8niOWBR82GaEZyE5+iG8wui2rHEfywE/ixiAnlVgYW7GZiPJZ4Fvklwz94z3Tv9586Lct/HALtNOR9I8H/RkyaJCDiAxJ7IYSpNxDq8rgFEvuOdHGkrdQ6PWfColPynpJZ4jiiCbYykv+EL/L+lVe3vlwZ33s/hE3PqADh/pq/jLHE4RpvPJTfbPtEzsg8WbQixfB/FhsnPA2bONYI6/aPMBPAYZ3eus/oQG3315DCEG4JftCHvRixP8vUeyftHYGLS7FoEbFfXZ4IeP4qDOoxWIAwbcwh/juBgeAq3m6TkMx2D/3C/eDIbfWOQC5G986oq56oRuKjQVEIF026z4DJNdjWgQ4L+Tlw3z0s4EAmZanNt/sPR/PQ58fv916IPoZu0hFxbxPxBxTWu38MfbBWGpJgo9Mx829JZDmcAFd3BuFcHT36SVq8Fm4jS/jYuKY3ICryb0MlFf5Y2Wz17/WttthJig3clJ2664OpBX0o+56OKPdQ320QuJwc3exppHpt0DjJZFZivrjjg4Z+YNIOMnunW7VQnKK7kRulyiyUdhYByzKc1se6KU3Nyff8rcFw3g1uiiKOSxcqXwf5TUDHmh3jHdW8WFZ4+kNtNU62f5rZ3/h8sGidouwkpPBB4SPDTbWC5T/EE= X-Forefront-Antispam-Report: CIP:66.129.239.15;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:p-exchfe-eqx-02.jnpr.net;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230025)(4636009)(376002)(136003)(396003)(346002)(39860400002)(451199018)(46966006)(40470700004)(36840700001)(8936002)(5660300002)(36860700001)(82740400003)(107886003)(81166007)(336012)(47076005)(82310400005)(186003)(6266002)(9686003)(26005)(7126003)(86362001)(316002)(55016003)(6916009)(40480700001)(54906003)(40460700003)(41300700001)(4326008)(558084003)(7696005)(70206006)(70586007)(478600001)(356005)(8676002)(2906002)(36900700001);DIR:OUT;SFP:1102; X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 Feb 2023 04:36:56.4792 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: e1de816d-5379-4fa0-90b6-08db1232eeb7 X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4;Ip=[66.129.239.15];Helo=[p-exchfe-eqx-02.jnpr.net] X-MS-Exchange-CrossTenant-AuthSource: DM6NAM12FT092.eop-nam12.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ0PR05MB7820 X-Proofpoint-GUID: CBqKDmwh-d5fCQIk94FPiBRf9M-GiHVp X-Proofpoint-ORIG-GUID: CBqKDmwh-d5fCQIk94FPiBRf9M-GiHVp X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.219,Aquarius:18.0.930,Hydra:6.0.562,FMLib:17.11.170.22 definitions=2023-02-19_01,2023-02-17_01,2023-02-09_01 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 bulkscore=0 phishscore=0 impostorscore=0 lowpriorityscore=0 clxscore=1011 mlxscore=0 malwarescore=0 spamscore=0 adultscore=0 priorityscore=1501 mlxlogscore=408 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2212070000 definitions=main-2302190043 X-Spamd-Result: default: False [-5.10 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; ARC_ALLOW(-1.00)[microsoft.com:s=arcselector9901:i=1]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.998]; DMARC_POLICY_ALLOW(-0.50)[juniper.net,reject]; R_SPF_ALLOW(-0.20)[+ip4:67.231.152.164]; R_DKIM_ALLOW(-0.20)[juniper.net:s=PPS1017,juniper.net:s=selector1]; MIME_GOOD(-0.10)[text/plain]; RCVD_IN_DNSWL_LOW(-0.10)[67.231.152.164:from]; RCPT_COUNT_FIVE(0.00)[5]; MIME_TRACE(0.00)[0:+]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:22843, ipnet:67.231.152.0/24, country:US]; RCVD_COUNT_TWELVE(0.00)[12]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; RCVD_IN_DNSWL_NONE(0.00)[40.93.10.11:received]; TO_DN_SOME(0.00)[]; FREEFALL_USER(0.00)[sjg]; DKIM_TRACE(0.00)[juniper.net:+]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[] X-Rspamd-Queue-Id: 4PKCSm6j53z3Dvc X-Spamd-Bar: ----- X-ThisMailContainsUnwantedMimeParts: N Stephane Rochoy wrote: > It may be worth contacting BearSSL's maintainer directly: Thomas > Pornin . The guy was very responsive and helpful > back in 2020 :) Indeed. From nobody Sun Feb 19 05:15:26 2023 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 4PKDJy10zYz3skY0 for ; Sun, 19 Feb 2023 05:15:30 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (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 "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4PKDJw6mMbz3HgD; Sun, 19 Feb 2023 05:15:28 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Authentication-Results: mx1.freebsd.org; dkim=none; spf=none (mx1.freebsd.org: domain of sgk@troutmask.apl.washington.edu has no SPF policy when checking 128.95.76.21) smtp.mailfrom=sgk@troutmask.apl.washington.edu; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=washington.edu (policy=none) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.17.1/8.17.1) with ESMTPS id 31J5FQja090694 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Sat, 18 Feb 2023 21:15:26 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.17.1/8.17.1/Submit) id 31J5FQxV090693; Sat, 18 Feb 2023 21:15:26 -0800 (PST) (envelope-from sgk) Date: Sat, 18 Feb 2023 21:15:26 -0800 From: Steve Kargl To: Dimitry Andric Cc: freebsd-current@freebsd.org Subject: Re: core dump in ld during buildworld Message-ID: Reply-To: sgk@troutmask.apl.washington.edu References: <25B4B3AD-3791-44D0-9FFA-7F1C2A9E82B9@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 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spamd-Result: default: False [-2.97 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-0.999]; NEURAL_HAM_SHORT(-0.98)[-0.976]; MIME_GOOD(-0.10)[text/plain]; DMARC_POLICY_SOFTFAIL(0.10)[washington.edu : No valid SPF, No valid DKIM,none]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_DKIM_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_SPF_NA(0.00)[no SPF record]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:73, ipnet:128.95.0.0/16, country:US]; TO_DN_SOME(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; ARC_NA(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; REPLYTO_ADDR_EQ_FROM(0.00)[]; HAS_REPLYTO(0.00)[sgk@troutmask.apl.washington.edu] X-Rspamd-Queue-Id: 4PKDJw6mMbz3HgD X-Spamd-Bar: -- X-ThisMailContainsUnwantedMimeParts: N On Sat, Feb 18, 2023 at 04:57:45PM -0800, Steve Kargl wrote: > > > > At that point it is still using the system compiler and linker, and it > > seems that the latter is lld. Do you know which version it is? > > > > Good question. Unfortunate ident(1) is useless in a git world. > > % ll /usr/bin/ld.lld > -r-xr-xr-x 1 root wheel - 41754432 Jan 15 12:03 /usr/bin/ld.lld > > This was built from source from Jan 15 2023. > > % /usr/bin/ld.lld --version > LLD 14.0.5 (FreeBSD llvmorg-14.0.5-0-gc12386ae247c-1400004) (compatible with GNU linkers) > So, is there some way to rebild only ld.lld and install a new loader? % cd /usr/src/usr.bin/clang/lld % make depend llvm-tblgen -gen-opt-parser-defs -I /usr/src/contrib/llvm-project/llvm/include -d Options.inc.d -o Options.inc /usr/src/contrib/llvm-project/lld/ELF/Options.td make: exec(llvm-tblgen) failed (No such file or directory) *** Error code 1 How to I fix this? -- Steve From nobody Sun Feb 19 06:55:18 2023 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 4PKGX03v9Jz3srTn for ; Sun, 19 Feb 2023 06:55:12 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ed1-x533.google.com (mail-ed1-x533.google.com [IPv6:2a00:1450:4864:20::533]) (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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4PKGWz00mmz3lZM for ; Sun, 19 Feb 2023 06:55:11 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20210112.gappssmtp.com header.s=20210112 header.b="OqK0sID/"; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2a00:1450:4864:20::533) smtp.mailfrom=wlosh@bsdimp.com; dmarc=none Received: by mail-ed1-x533.google.com with SMTP id ee44so4661300edb.5 for ; Sat, 18 Feb 2023 22:55:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20210112.gappssmtp.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=g3393x33pM/U10tfVbf8ydifh8/64vJgr/olaNHmvQU=; b=OqK0sID/6cYNHXHHoJogJuQ6kAyqDOLhqQGGLtzcqXob16j6XDcX9x1RVItLm4SRTp 7rAFJi1U4Xfpxvgq5sOxBATyNERQnaiGfNUSF3e9Gbsvy9/gDqmymCmpWiXf2t4qMaJC pC5sSr2gpPCLC3bSiUkgTPlXesQ46xN8gnHjZBXdF+XSilu25Zq6XmkBMb7zck0OTuwj 3ca6u9+xOL04wofdcUSOKVOgBl+luasj0Rmzvhtk6e3fSnYG664E6+v9KgQVNbvCJlVQ Z2NzNpDQo9frJz5GsMN92E3BScMO+ynLI/4gFFI7y6Iwh/U00yK2Yysv6n3+3hEZi8bf LNoA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=g3393x33pM/U10tfVbf8ydifh8/64vJgr/olaNHmvQU=; b=2pcl+fufZlfEZxj/+aI2DhCqkQHA6ATb2/xptD3oLuvyqgRtO7q0KY+xZOoFh4U61X DhstfkaDyohPgg38kJgZkNo4q1Lxw+oYcxAb6VrnEEMqEl/z1ESRa4IvVWUMiqgh6jBI s825mCXCZTJuz3eEjmt9ZdcoZQokNZPgWaeB0mL5mEBb+42eI5urDlcIg4FBChaaiW0s QsLYx6iPInDfg4P7w91l4M8BYf2d4PlBWD7bmMBHdW1m8HRPUFG+n3cVlT3aNrSby2Oc 5n4XBssjV8fxRakITteMRuDLGRonBkEQASBmcFDrfNDEtZ6Fwn6Np/KeeFytX18WLk8V 1zCg== X-Gm-Message-State: AO0yUKVeJ1Fl34Kt3Qz++ME/Yh3LpaUgXpl/EVC5076HOGeFECMyZ7Uk ew8wfykdqU9cAQxXPa2c6ReY71poveIUdGH0sjDFcw== X-Google-Smtp-Source: AK7set8fFuT0DgUoV0ZcqdiuJtrTb1xYLkHv9gny1ZTLqFK7sfQ+Dl6+oYEEmw0due6knWbgLGftWX9IOVLh1inDTsw= X-Received: by 2002:a50:9fa6:0:b0:4ad:72b2:cf57 with SMTP id c35-20020a509fa6000000b004ad72b2cf57mr873719edf.0.1676789708929; Sat, 18 Feb 2023 22:55:08 -0800 (PST) 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 MIME-Version: 1.0 References: In-Reply-To: From: Warner Losh Date: Sat, 18 Feb 2023 23:55:18 -0700 Message-ID: Subject: Re: Build breakage with WITH_BEARSSL=1 To: Gordon Bergling Cc: FreeBSD Current Content-Type: multipart/alternative; boundary="000000000000f6d36105f50806c5" X-Spamd-Result: default: False [-3.00 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20210112.gappssmtp.com:s=20210112]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; ARC_NA(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; R_SPF_NA(0.00)[no SPF record]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::533:from]; DKIM_TRACE(0.00)[bsdimp-com.20210112.gappssmtp.com:+]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; DMARC_NA(0.00)[bsdimp.com]; TO_DN_ALL(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-Rspamd-Queue-Id: 4PKGWz00mmz3lZM X-Spamd-Bar: -- X-ThisMailContainsUnwantedMimeParts: N --000000000000f6d36105f50806c5 Content-Type: text/plain; charset="UTF-8" On Thu, Feb 16, 2023 at 12:57 AM Gordon Bergling wrote: > Hi Warner, > > On Wed, Feb 15, 2023 at 10:07:08AM -0700, Warner Losh wrote: > > On Sun, Feb 12, 2023, 3:18 PM Warner Losh wrote: > > > On Sun, Feb 12, 2023 at 3:54 AM Gordon Bergling > wrote: > > > > > >> Hi, > > >> > > >> I am currently seeing a build breakage when building -CURRENT with > > >> WITH_BEARSSL=1. > > >> > > >> The error is the following > > >> > > >> make[5]: "/boiler/nfs/src/lib/libsecureboot/local.trust.mk" line > 109: > > >> warning: "cd /boiler/nfs/src/lib/libsecureboot && 'ls' -1 *.pem > t*.asc 2> > > >> /dev/null" returned non-zero status > > >> /boiler/nfs/src/contrib/bearssl/src/rsa/rsa_i62_keygen.c:43:22: > error: > > >> a function declaration without a prototype is deprecat ed in all > versions > > >> of C [-Werror,-Wstrict-prototypes] > > >> br_rsa_i62_keygen_get() > > >> ^ > > >> void > > >> 1 error generated. > > >> --- rsa_i62_keygen.pico --- > > >> > > >> > > >> When disabling BEARSSL in the src.conf the build succeeds as usual. > > >> > > >> Has anyone also seen this build error. Sources are very recent and the > > >> src.conf is the following: > > >> > > >> WITH_EXTRA_TCP_STACKS=1 > > >> #WITH_BEARSSL=1 > > >> WITH_PIE=1 > > >> WITH_RETPOLINE=1 > > >> WITH_INIT_ALL_ZERO=1 > > >> WITH_OPENSSL_KTLS=1 > > >> WITHOUT_CLEAN=1 > > >> > > >> Any help is very appreciated. > > >> > > >> > > > What does the following do for you? It's a cut and pasted patch, but it > > > should be clear enough what to do if the mailer mangles it. > > > > > > diff --git a/lib/libbearssl/Makefile.inc b/lib/libbearssl/Makefile.inc > > > index dd0e242c8ef0..2af4864d8441 100644 > > > --- a/lib/libbearssl/Makefile.inc > > > +++ b/lib/libbearssl/Makefile.inc > > > @@ -4,4 +4,4 @@ BEARSSL?= ${SRCTOP}/contrib/bearssl > > > BEARSSL_SRC= ${BEARSSL}/src > > > > > > CFLAGS+= -I${BEARSSL}/inc > > > - > > > +CFLAGS+= ${NO_WDEPRECATED_NON_PROTOTYPE} > > > > > > > I went ahead and committed this. Please let me know if the problem > persists. > > Sorry for the late reply. I just tried a fresh build and it still fails > with > > [..]/src/contrib/bearssl/src/rsa/rsa_i62_keygen.c:43:22: error: a function > declaration without a prototype is deprecated in all versions of C > [-Werror,-Wstrict-prototypes] > br_rsa_i62_keygen_get() > > Did you see any other possibilty to fix this? > Oh, maybe add -Wno-strict-prototypes to where I added NO_WDEPRECATED_NON_PROTOTYPES? Warner --000000000000f6d36105f50806c5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Feb 16, 2023 at 12:57 AM Gord= on Bergling <gbe@freebsd.org> = wrote:
Hi Warner= ,

On Wed, Feb 15, 2023 at 10:07:08AM -0700, Warner Losh wrote:
> On Sun, Feb 12, 2023, 3:18 PM Warner Losh <imp@bsdimp.com> wrote:
> > On Sun, Feb 12, 2023 at 3:54 AM Gordon Bergling <gbe@freebsd.org> wrote:
> >
> >> Hi,
> >>
> >> I am currently seeing a build breakage when building -CURRENT= with
> >> WITH_BEARSSL=3D1.
> >>
> >> The error is the following
> >>
> >>=C2=A0 =C2=A0make[5]: "/boiler/nfs/src/lib/libsecureboot/= loca= l.trust.mk" line 109:
> >> warning: "cd /boiler/nfs/src/lib/libsecureboot &&= ; 'ls'=C2=A0 =C2=A0-1 *.pem t*.asc 2>
> >> /dev/null" returned non-zero status
> >>=C2=A0 =C2=A0/boiler/nfs/src/contrib/bearssl/src/rsa/rsa_i62_k= eygen.c:43:22: error:
> >> a function declaration without a prototype is deprecat=C2=A0 = ed in all versions
> >> of C [-Werror,-Wstrict-prototypes]
> >>=C2=A0 =C2=A0br_rsa_i62_keygen_get()
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 ^
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0void
> >>=C2=A0 =C2=A01 error generated.
> >>=C2=A0 =C2=A0--- rsa_i62_keygen.pico ---
> >>
> >>
> >> When disabling BEARSSL in the src.conf the build succeeds as = usual.
> >>
> >> Has anyone also seen this build error. Sources are very recen= t and the
> >> src.conf is the following:
> >>
> >> WITH_EXTRA_TCP_STACKS=3D1
> >> #WITH_BEARSSL=3D1
> >> WITH_PIE=3D1
> >> WITH_RETPOLINE=3D1
> >> WITH_INIT_ALL_ZERO=3D1
> >> WITH_OPENSSL_KTLS=3D1
> >> WITHOUT_CLEAN=3D1
> >>
> >> Any help is very appreciated.
> >>
> >>
> > What does the following do for you? It's a cut and pasted pat= ch, but it
> > should be clear enough what to do if the mailer mangles it.
> >
> > diff --git a/lib/libbearssl/Makefile.inc b/lib/libbearssl/Makefil= e.inc
> > index dd0e242c8ef0..2af4864d8441 100644
> > --- a/lib/libbearssl/Makefile.inc
> > +++ b/lib/libbearssl/Makefile.inc
> > @@ -4,4 +4,4 @@ BEARSSL?=3D ${SRCTOP}/contrib/bearssl
> >=C2=A0 BEARSSL_SRC=3D ${BEARSSL}/src
> >
> >=C2=A0 CFLAGS+=3D -I${BEARSSL}/inc
> > -
> > +CFLAGS+=3D ${NO_WDEPRECATED_NON_PROTOTYPE}
> >
>
> I went ahead and committed this. Please let me know if the problem per= sists.

Sorry for the late reply. I just tried a fresh build and it still fails wit= h

[..]/src/contrib/bearssl/src/rsa/rsa_i62_keygen.c:43:22: error: a function<= br> declaration without a prototype is deprecated in all versions of C [-Werror= ,-Wstrict-prototypes]
=C2=A0 br_rsa_i62_keygen_get()

Did you see any other possibilty to fix this?

Oh, maybe add -Wno-strict-prototypes to where I added NO_WDEPRECATED= _NON_PROTOTYPES?

Warner
--000000000000f6d36105f50806c5-- From nobody Sun Feb 19 09:37:40 2023 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 4PKL8J4Vkpz3t3WG for ; Sun, 19 Feb 2023 09:38:24 +0000 (UTC) (envelope-from freebsd@walstatt-de.de) Received: from smtp6.goneo.de (smtp6.goneo.de [IPv6:2001:1640:5::8:31]) (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 4PKL8H3z3kz3yJH for ; Sun, 19 Feb 2023 09:38:23 +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=NlXLKHvp; spf=none (mx1.freebsd.org: domain of freebsd@walstatt-de.de has no SPF policy when checking 2001:1640:5::8:31) smtp.mailfrom=freebsd@walstatt-de.de; dmarc=none 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 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by smtp6.goneo.de (Postfix) with ESMTPS id 4646C10A1E80 for ; Sun, 19 Feb 2023 10:38:14 +0100 (CET) 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 (2048 bits)) (No client certificate requested) by hub1.goneo.de (Postfix) with ESMTPS id 2B02E10A32F4 for ; Sun, 19 Feb 2023 10:38:10 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=walstatt-de.de; s=DKIM001; t=1676799490; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=sr9GGUq2rQoQCKZt6VHhUu+6VkCS4ughHkl1Lujfyac=; b=NlXLKHvpev0Hp1IegL/yNN2/Ri5Ca+lEz3ioMf+Pwf3h2znTYPzsrGStjoNKsFnanO51LT pDK3PCgdEBSpx3iJJgXY0/u+NXzefiZ29ABMNXvoXTwT9DErLmdu9CTtjeNNp+wmrPM6jA PCGt5BLHPVdTbCpolSUPMKixa1heA4dWDtSHPYoKM8KyIu78HKaf7q45AbOo31AM5zWn5J y8JASCAa2w9kBHF6ocnXT2GHVBAr4xbJgudCjjKkrzBlwQpehvh1FFoMl8NkKNkpt9+fjD 8KP+Aas5hS8wSCxH84ooypvV2vbx3sbyPVb4XzOXm7rNktHSZMy97zehh5vTEQ== Received: from thor.intern.walstatt.dynvpn.de (dynamic-078-054-146-144.78.54.pool.telefonica.de [78.54.146.144]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by hub1.goneo.de (Postfix) with ESMTPSA id EC7AB10A3312 for ; Sun, 19 Feb 2023 10:38:09 +0100 (CET) Date: Sun, 19 Feb 2023 10:37:40 +0100 From: FreeBSD User To: FreeBSD CURRENT Subject: CURRENT: Crash in multiuser mode while shutdown Message-ID: <20230219103807.38798427@thor.intern.walstatt.dynvpn.de> Organization: walstatt-de.de 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 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-UID: 9b105f X-Rspamd-UID: c2401b X-Spamd-Result: default: False [-3.30 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[walstatt-de.de:s=DKIM001]; MIME_GOOD(-0.10)[text/plain]; DKIM_TRACE(0.00)[walstatt-de.de:+]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_NA(0.00)[no SPF record]; TO_DN_ALL(0.00)[]; MIME_TRACE(0.00)[0:+]; FROM_EQ_ENVFROM(0.00)[]; RCVD_COUNT_THREE(0.00)[4]; RCPT_COUNT_ONE(0.00)[1]; ASN(0.00)[asn:25394, ipnet:2001:1640::/32, country:DE]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; HAS_ORG_HEADER(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DMARC_NA(0.00)[walstatt-de.de]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; RCVD_TLS_ALL(0.00)[] X-Rspamd-Queue-Id: 4PKL8H3z3kz3yJH X-Spamd-Bar: --- X-ThisMailContainsUnwantedMimeParts: N Hello, most recent CURRENT crashes on shutdown from multiuser mode (singleuser mode, used after repairing failed FFS filesystems, is all right). The crashes go on since roughly a 1/2 week from now. The boxes involved are all cumtomized kernels (in most cases hard linked modules into kernel). Is there a known issue? Otherwise I have to reconfigure all systems for debugging an d will report aftwards more. Regards and thanks in advance Oliver -- O. Hartmann From nobody Sun Feb 19 10:30:13 2023 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 4PKMJB2s9fz3kj0g; Sun, 19 Feb 2023 10:30:18 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from forward502c.mail.yandex.net (forward502c.mail.yandex.net [178.154.239.210]) (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 4PKMJB0B0Gz447B; Sun, 19 Feb 2023 10:30:17 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Authentication-Results: mx1.freebsd.org; none Received: from myt6-fe378243d6ea.qloud-c.yandex.net (myt6-fe378243d6ea.qloud-c.yandex.net [IPv6:2a02:6b8:c12:488f:0:640:fe37:8243]) by forward502c.mail.yandex.net (Yandex) with ESMTP id E82865EB1D; Sun, 19 Feb 2023 13:30:14 +0300 (MSK) Received: by myt6-fe378243d6ea.qloud-c.yandex.net (smtp/Yandex) with ESMTPSA id DUlPW9NZIW21-ETMddzIb; Sun, 19 Feb 2023 13:30:14 +0300 X-Yandex-Fwd: 1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1676802614; bh=4Ag47R0wfbmeRvKe+8lTlRmmq6o5VbthCJOEQaPBHl0=; h=In-Reply-To:Subject:From:References:To:Date:Message-ID; b=Sii1+aZiJMfKl8p867uvpFePw/BplGoZvBuOOyUclOwHSdZbXsJETCC0gdHtp1BBz mKFi4orS/wpUioTKrrTJMsWoFR4jcsUXlqpxkNUPcokmZDJyIB1pbFLUYQe+DWgOlP 7k3l+KrCahdNKpVC38M6csNPwVe9cqVuLQJwK2a8= Message-ID: <40222458-bae1-bff3-b65c-2c3f26705f10@yandex.ru> Date: Sun, 19 Feb 2023 13:30:13 +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 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:102.0) Gecko/20100101 Thunderbird/102.6.1 Content-Language: en-US To: FreeBSD User , freebsd-net@freebsd.org, FreeBSD CURRENT References: <20230218164325.3a4c626a@thor.intern.walstatt.dynvpn.de> From: "Andrey V. Elsukov" Subject: Re: IPFW: IPv6 and NPTv6 issues: multiple IPv6 addresses confuses IPFW In-Reply-To: <20230218164325.3a4c626a@thor.intern.walstatt.dynvpn.de> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------o0TJuDGmcyW4MwcT2vQXhe6Z" X-Rspamd-Queue-Id: 4PKMJB0B0Gz447B X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:200350, ipnet:178.154.224.0/19, country:RU] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------o0TJuDGmcyW4MwcT2vQXhe6Z Content-Type: multipart/mixed; boundary="------------G2U7S0qAURtAPdyXAvuQO5YH"; protected-headers="v1" From: "Andrey V. Elsukov" To: FreeBSD User , freebsd-net@freebsd.org, FreeBSD CURRENT Message-ID: <40222458-bae1-bff3-b65c-2c3f26705f10@yandex.ru> Subject: Re: IPFW: IPv6 and NPTv6 issues: multiple IPv6 addresses confuses IPFW References: <20230218164325.3a4c626a@thor.intern.walstatt.dynvpn.de> In-Reply-To: <20230218164325.3a4c626a@thor.intern.walstatt.dynvpn.de> --------------G2U7S0qAURtAPdyXAvuQO5YH Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 MTguMDIuMjAyMyAxODo0MiwgRnJlZUJTRCBVc2VyINC/0LjRiNC10YI6DQo+IE9uIGEgMjQg aG91ciBiYXNpcywgdGhlIElTUCBjaGFuZ2VzIHRoZSBJUHY0IGFuZCBJUHY2IG9uIHRoZSBX QU4NCj4gaW50ZXJmYWNlLiBXZSB1c2UgTlBUdjYgdG8gdHJhbnNsYXRlICBVTEEgYWRkcmVz c2VzIGZvciB0aGUgaW5uZXINCj4gSVB2NiBuZXR3b3Jrcy4gV2UgdXNlIElQdjYgcHJpdmFj eSBvbiB0aGUgdHVuMCBpbnRlcmZhY2UuIFRoZQ0KPiByb3V0ZXIvZmlyZXdhbGwgaXMgb3Bl cmF0aW5nIGFmdGVyIGEgcmVib290IG9yIHJlc3RhcnQgb2YgbXBkNQ0KPiBjb3JyZWN0bHks IElQdjYgYW5kIElQdjQgbmV0d29ya3MgaGF2ZSBjb25lY3Rpb24gdG8gdGhlIGludGVybmV0 Lg0KPiBXaGVuIHRoZSBJU1Agcm90YXRlcyBpdCBJUHMsIHRoZSBJUHY2IGFkZHJlc3MgaXMg Y29uZmlndXJlZCB1c2luZw0KPiBTTEFBQyBhbmQgbXBkNSBzZWVtcyB0byBhY3Qgd2VpcmQ6 DQo+IA0KPiAtIHRoZSBJUHY0IGFkZHJlc3MgaXMgYWx3YXlzIHNldCBjb3JyZWN0LCBJUEZX IGFuZCBpbi1rZXJuZWwgTkFUDQo+IHJvdXRlL2ZpbHRlciB0cmFmZmljIGNvcnJlY3RseSAt IHNvbWV0aW1lcyBvbGQgSVB2NiBhZGRyZXNzIGlzIGR1bXBlZA0KPiBhbmQgb25seSBhIG5l dyBJUHY2IGFkZHJlc3MgLSBpbiBzdWNoIGEgY2FzZSwgdGhlIG9sZCBJUHY2IGlzIGdvbmUs DQo+IHRoZSBuZXcgcGFpciAodGVtcG9yYXJ5IGFuZCBNQUNpZmllZCBhZGRyZXNzIGFyZSB0 aGUgb25seSBJUHY2DQo+IGFkZHJlc3NlcyBhdHRhY2hlZCB0byB0aGUgaW50ZXJmYWNlLiAt IHNvbWV0aW1lcyB0aGUgb2xkIElQdjYgYWRkcmVzcw0KPiBzZXQgKD0gdGVtcG9yYXJ5KSBh cmUgbWFya2VkICJkZXByZWNhdGVkIiBhbmQvb3IgImRldGFjaGVkIiBhbmQgYSBuZXcNCj4g c2V0IGlzIGF0dGFjaGVkIHRvIHRoZSBpbnRlcmZhY2UgdHVuMCwgaW4gc29tZSByYXJlIG9j Y2Fzc2lvbiBhbHNvIGFuDQo+IElQdjYgYWRkcmVzcyBXSVRIT1VUIGl0cyAidGVtb3ByYXJ5 IiBzaWJibGluZyBpcyBhdHRhY2hlZC4NCj4gDQo+IEluIGFueSBvZiB0aGUgY2FzZXMgYWJv dmUsIElQRlcncyBOUFR2NiBnZXRzIGNvbmZ1c2VkLCByb3V0aW5nIGlzbid0DQo+IHdvcmtp bmcgcHJvcGVybHkgYW55bW9yZS4NCj4gDQo+IEluIGFueSBjYXNlcyBvZiBhIGNoYW5nZSBv ZiB0aGUgSVB2NiBhZGRyZXNzLCBJUEZXIGhhcyB0byBiZQ0KPiByZXN0YXJ0ZXQhDQoNCkhp LA0KDQpJIGFzc3VtZSB5b3UgYXJlIHVzaW5nIGV4dF9pZiBvcHRpb24gaW4geW91ciBOUFR2 NiBpbnN0YW5jZSBjb25maWd1cmF0aW9uLg0KDQpJIHRoaW5rIHRoZXJlIG1pZ2h0IGJlIHNl dmVyYWwgcHJvYmxlbXMgdGhhdCBsZWFkIHRvIHlvdXIgc2l0dWF0aW9uOg0KDQoxLiBOUFR2 NiB0cmFja3MgSVB2NiBhZGRyZXNzZXMgZGVsZXRpb24sIGJ1dCBzaW5jZSBhbiBvbGQgSVB2 NiBhZGRyZXNzIA0KdGhhdCB3YXMgdXNlZCBhcyBleHRlcm5hbCBwcmVmaXggIGtlcHQgb24g dGhlIGludGVyZmFjZSwgaXQgaWdub3JlcyANCmFwcGVhcmFuY2Ugb2YgbmV3IElQdjYgYWRk cmVzcy4NCg0KMi4gVGhlbiwgZXZlbiBpZiB5b3UgZGVsZXRlIG9sZCBJUHY2IGFkZHJlc3Mg YnkgaGFuZCwgTlBUdjYgd29uJ3QgdHJ5IHRvIA0KcGVhayBhbm90aGVyIG9uZSB1bnRpbCB0 aGVyZSB3b24ndCBhcHBlYXIgbmV3IGFkZHJlc3MuDQoNCjMuIFRoZXJlIHNob3VsZCBiZSBz b21lIGxvZ2ljIHRoYXQgdGFrZXMgaW50byBhY2NvdW50IHByZXNlbmNlIG9mIA0KdGVtcG9y YXJ5IGFuZCBkZXByZWNhdGVkIGFkZHJlc3NlcyBvbiB0aGUgaW50ZXJmYWNlLg0KDQotLSAN CldCUiwgQW5kcmV5IFYuIEVsc3Vrb3YNCg0K --------------G2U7S0qAURtAPdyXAvuQO5YH-- --------------o0TJuDGmcyW4MwcT2vQXhe6Z Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEE5lkeG0HaFRbwybwAAcXqBBDIoXoFAmPx+jUFAwAAAAAACgkQAcXqBBDIoXoP YQf+L7WYPvfUkVB9MhMjwxAUFHIpq7gUAWJoHMh+3OzlzNEC15+KAIDk+bmUJMLy4CEp5aCdwK51 W0mROPbTrGlhhiR4zkPrUybhJSjsfYCsKyk7QVj8AHk04ANA5oSoq2oSoBOOIO0/2J73engRZtoz VHA4Ud/Gp9JeNW1A53UMmoFXk29X+5XO2vsreYbyFVQAmQz/LbfncLkM7DOzawr1m2pHVBEeiG6g bUvIcf3P8/Z4mh5uCmktHUwUwdqNd7zUZz8JcauyiYV6xd/PWJ/Q1N3BEE7JCGjWY0wWGr6i15C/ 82WuqXyTvYbLwEcboJ7GquOlDW3ATgFiL0cbDNlvoQ== =zP1j -----END PGP SIGNATURE----- --------------o0TJuDGmcyW4MwcT2vQXhe6Z-- From nobody Sun Feb 19 11:06:58 2023 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 4PKN6f07T5z3klhJ for ; Sun, 19 Feb 2023 11:07:06 +0000 (UTC) (envelope-from mikej@mikej.com) Received: from mail2.mikej.com (mail2.mikej.com [157.245.3.2]) (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 "digitalocean", Issuer "digitalocean" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4PKN6b5xnMz4B1Y for ; Sun, 19 Feb 2023 11:07:03 +0000 (UTC) (envelope-from mikej@mikej.com) Authentication-Results: mx1.freebsd.org; dkim=none; spf=pass (mx1.freebsd.org: domain of mikej@mikej.com designates 157.245.3.2 as permitted sender) smtp.mailfrom=mikej@mikej.com; dmarc=pass (policy=none) header.from=mikej.com Received: from 250-71-150-188-187.lightspeed.lsvlky.sbcglobal.net (71-150-188-187.lightspeed.lsvlky.sbcglobal.net [71.150.188.187]) by mail2.mikej.com (8.16.1/8.16.1) with ESMTPS id 31JB6xPV020241 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=FAIL) for ; Sun, 19 Feb 2023 11:06:59 GMT (envelope-from mikej@mikej.com) Received: from [192.168.6.10] (office.mikej.local [192.168.6.10]) by mikej.com (8.17.1/8.17.1) with ESMTP id 31JB6taC012886 for ; Sun, 19 Feb 2023 06:06:55 -0500 (EST) (envelope-from mikej@mikej.com) X-Authentication-Warning: firewall.mikej.com: Host office.mikej.local [192.168.6.10] claimed to be [192.168.6.10] Message-ID: <5e1ecc29-9ce3-9588-fd12-0384a6b35815@mikej.com> Date: Sun, 19 Feb 2023 06:06:58 -0500 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 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.6.1 Content-Language: en-US From: Michael Jung Subject: FreeBSD 13.2-stable crash in /usr/src/sys/amd64/include/pcpu_aux.h:55 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spamd-Result: default: False [-3.80 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.999]; NEURAL_HAM_LONG(-1.00)[-0.999]; DMARC_POLICY_ALLOW(-0.50)[mikej.com,none]; R_SPF_ALLOW(-0.20)[+ip4:157.245.3.2/32]; MIME_GOOD(-0.10)[text/plain]; R_DKIM_NA(0.00)[]; ASN(0.00)[asn:14061, ipnet:157.245.0.0/20, country:US]; MIME_TRACE(0.00)[0:+]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; ARC_NA(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; RCVD_TLS_LAST(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; HAS_XAW(0.00)[]; MID_RHS_MATCH_FROM(0.00)[] X-Rspamd-Queue-Id: 4PKN6b5xnMz4B1Y X-Spamd-Bar: --- X-ThisMailContainsUnwantedMimeParts: N After upgrading from FreeBSD firewall.mikej.com 13.1-STABLE FreeBSD 13.1-STABLE #21 stable/13-n253337-16603f60156e:Wed Dec 28 08:22:48 EST 2022 mikej@firewall.mikej.com:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64 TO FreeBSD firewall.mikej.com 13.2-STABLE FreeBSD 13.2-STABLE #3 stable/13-n254483-e0c3f2a1e296: Tue Feb 14 19:25:51 EST 2023 mikej@firewall.mikej.com:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64 I had a kernel crash which can be found here. http://mail.mikej.com/core.txt.0 It has not happened again, but I'm putting it though it's normal paces. The only thing that was occurring which is not a normal thing for me to is I was moving TB's worth of data between directly attached two zpools. Regards, Michael Jung From nobody Sun Feb 19 11:24:54 2023 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 4PKNWw0zbRz3knLK; Sun, 19 Feb 2023 11:25:32 +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 4PKNWv4BVWz4FL3; Sun, 19 Feb 2023 11:25:31 +0000 (UTC) (envelope-from freebsd@walstatt-de.de) Authentication-Results: mx1.freebsd.org; none Received: from hub2.goneo.de (hub2.goneo.de [85.220.129.53]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by smtp5.goneo.de (Postfix) with ESMTPS id B7E4E10A1E8B; Sun, 19 Feb 2023 12:25:29 +0100 (CET) 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 (2048 bits)) (No client certificate requested) by hub2.goneo.de (Postfix) with ESMTPS id 2901910A3312; Sun, 19 Feb 2023 12:25:28 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=walstatt-de.de; s=DKIM001; t=1676805928; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=/ofD534/T83ekiMN0IPQWj0yDOeMdqyAoSjlD1nEYkI=; b=a1nCOicH6q+/08df5VwB6Nk46Olccbkj/0jR6SNBMzcMSCXUFMlRlW2ngA9JUfxgt4oQss HTewF1o0S2NAKvEeXySdSm8SpQWNjrZ3kfWFNrWfvtvH+Due5b3a9C7mSTvYIVG9MQ3796 hoyTbNfo7sQFGHk4dCIRdng+k+O3iI7nK6BqgqWs7/HLgjkAl3lAAGuhznRw2G89DkwROK IJMOLszZ/vr6ZQxAiMIDwcmuN11B4zkslL5u4fJQRKUvigtsWlEvC7kaSw5or1ZqX5NYTQ hQHZ+4nSMeuSmURgAiHeH6CPjIi5dhFhVvFMayVY6vZ3/mpdveYK9GwVGZ2NkQ== Received: from thor.intern.walstatt.dynvpn.de (dynamic-078-054-146-144.78.54.pool.telefonica.de [78.54.146.144]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by hub2.goneo.de (Postfix) with ESMTPSA id E3FC110A3308; Sun, 19 Feb 2023 12:25:27 +0100 (CET) Date: Sun, 19 Feb 2023 12:24:54 +0100 From: FreeBSD User To: "Andrey V. Elsukov" Cc: freebsd-net@freebsd.org, FreeBSD CURRENT Subject: Re: IPFW: IPv6 and NPTv6 issues: multiple IPv6 addresses confuses IPFW Message-ID: <20230219122521.6c3d5bdb@thor.intern.walstatt.dynvpn.de> In-Reply-To: <40222458-bae1-bff3-b65c-2c3f26705f10@yandex.ru> References: <20230218164325.3a4c626a@thor.intern.walstatt.dynvpn.de> <40222458-bae1-bff3-b65c-2c3f26705f10@yandex.ru> Organization: walstatt-de.de 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 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Sig_/IIvB9JOlsSxvOY+u_seJ6.M"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Rspamd-UID: 57f406 X-Rspamd-UID: 8f7237 X-Rspamd-Queue-Id: 4PKNWv4BVWz4FL3 X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:25394, ipnet:85.220.128.0/17, country:DE] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N --Sig_/IIvB9JOlsSxvOY+u_seJ6.M Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Am Sun, 19 Feb 2023 13:30:13 +0300 "Andrey V. Elsukov" schrieb: > 18.02.2023 18:42, FreeBSD User =D0=BF=D0=B8=D1=88=D0=B5=D1=82: > > On a 24 hour basis, the ISP changes the IPv4 and IPv6 on the WAN > > interface. We use NPTv6 to translate ULA addresses for the inner > > IPv6 networks. We use IPv6 privacy on the tun0 interface. The > > router/firewall is operating after a reboot or restart of mpd5 > > correctly, IPv6 and IPv4 networks have conection to the internet. > > When the ISP rotates it IPs, the IPv6 address is configured using > > SLAAC and mpd5 seems to act weird: > >=20 > > - the IPv4 address is always set correct, IPFW and in-kernel NAT > > route/filter traffic correctly - sometimes old IPv6 address is dumped > > and only a new IPv6 address - in such a case, the old IPv6 is gone, > > the new pair (temporary and MACified address are the only IPv6 > > addresses attached to the interface. - sometimes the old IPv6 address > > set (=3D temporary) are marked "deprecated" and/or "detached" and a new > > set is attached to the interface tun0, in some rare occassion also an > > IPv6 address WITHOUT its "temoprary" sibbling is attached. > >=20 > > In any of the cases above, IPFW's NPTv6 gets confused, routing isn't > > working properly anymore. > >=20 > > In any cases of a change of the IPv6 address, IPFW has to be > > restartet! =20 >=20 > Hi, >=20 > I assume you are using ext_if option in your NPTv6 instance configuration. That is correct. >=20 > I think there might be several problems that lead to your situation: >=20 > 1. NPTv6 tracks IPv6 addresses deletion, but since an old IPv6 address=20 > that was used as external prefix kept on the interface, it ignores=20 > appearance of new IPv6 address. >=20 > 2. Then, even if you delete old IPv6 address by hand, NPTv6 won't try to= =20 > peak another one until there won't appear new address. >=20 > 3. There should be some logic that takes into account presence of=20 > temporary and deprecated addresses on the interface. >=20 --=20 O. Hartmann --Sig_/IIvB9JOlsSxvOY+u_seJ6.M Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iHUEARYKAB0WIQRQheDybVktG5eW/1Kxzvs8OqokrwUCY/IHIQAKCRCxzvs8Oqok r7mGAP9DbwB6FVttlEO1dP+u+jF90RdRAzICGtQ04hZqwypBLAEAwzXi3soPKKAs 8QS6nM1Gt6zK6ssNwEwBdwQPhENllgM= =Zt7F -----END PGP SIGNATURE----- --Sig_/IIvB9JOlsSxvOY+u_seJ6.M-- From nobody Sun Feb 19 12:57:10 2023 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 4PKQYh2VQrz3kvg4 for ; Sun, 19 Feb 2023 12:57:12 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: from mail-oa1-x2a.google.com (mail-oa1-x2a.google.com [IPv6:2001:4860:4864:20::2a]) (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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4PKQYg4JCPz4QJm; Sun, 19 Feb 2023 12:57:11 +0000 (UTC) (envelope-from mjguzik@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-oa1-x2a.google.com with SMTP id 586e51a60fabf-171dfaa208aso312933fac.0; Sun, 19 Feb 2023 04:57:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:references:in-reply-to :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=S9Nwe5nwwWLBVIHqSM+aQXeBezOJqKLhsUkyJZhz9HM=; b=Mh434sYuK62p1q/zkahiqRb18j2TWSxvfUT+F1j2HvnZM1vbfmjDFaDxODIxAwWhvZ 89NWgFT5uGQsmW1Wjzr+U9PNkFukZU1xFPCP2jHZTOpSK8RpglfRFpotMkIj3WAG7qdZ U1oFMlXhKUlN5rwPTd0BNFLqT7QFfYbh626nTh9yMvDZ8LrnvxQyQd+VvpL4ZJhXpE8U 80CLus2IY7WivNyIelJzxManVz1LEDY9VuCO06qdmx7EdcjyHGbdWuRjrkL8mrUEljNN pHY1JdAYunK+Ky18m/2Y9lNMNdfrGE2z6lcOqTiMx3X9hbJVYDy2EutPWv7NlE1plmiX GGGQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:references:in-reply-to :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=S9Nwe5nwwWLBVIHqSM+aQXeBezOJqKLhsUkyJZhz9HM=; b=wm7K+SLGkKjtm3k3BUiCqK7kPXJNtLhCBaDaebEPOhVypc+oeu+a3um+tKD7xNH2B1 Bgcf+ZbJRLwJHc8MA/ESIi789B6WjCdcROhA74m30Jof6yIPcMh9vhCPAtmqRzp29E9G SU583dnf0PuaLCOD/FPJToOGw9REFY9QHMCBNnJQjHNOb96iop1ILx0B19fXJF7CTeGG 1IgZ9he7GiSa7cZUK6MBj7rh68WpMZF4RCDtqS3F8kYpfxR0Qe59oRa4JtSdtachgLAt 71GAel+oRG/ufsF2FyiyCdyvonktS0jVbsf+LJELFxH8t3WrkKjMlC6so4BslQAXsgmg PLZA== X-Gm-Message-State: AO0yUKUkv3owUbxxMBnhkZc5WY/tvnkXTHK4oVZijevhOfeb27+sW2d9 mMBtzRu5ycM4z2pEGX6ntFwGc7mlGwl30m9AExjKoHod X-Google-Smtp-Source: AK7set8mIdVifHvPcDvvSbvR/KY8RVfSgItLr94uuJTdPSQ5xIhh1Rc4/d46jGqgG3UUB+yA+nr+CUDH8K22w3h4tLM= X-Received: by 2002:a05:6870:fb8c:b0:15f:1d8a:8860 with SMTP id kv12-20020a056870fb8c00b0015f1d8a8860mr990749oab.153.1676811430588; Sun, 19 Feb 2023 04:57:10 -0800 (PST) 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 MIME-Version: 1.0 Received: by 2002:ac9:5dc5:0:b0:49c:b071:b1e3 with HTTP; Sun, 19 Feb 2023 04:57:10 -0800 (PST) In-Reply-To: <5e1ecc29-9ce3-9588-fd12-0384a6b35815@mikej.com> References: <5e1ecc29-9ce3-9588-fd12-0384a6b35815@mikej.com> From: Mateusz Guzik Date: Sun, 19 Feb 2023 13:57:10 +0100 Message-ID: Subject: Re: FreeBSD 13.2-stable crash in /usr/src/sys/amd64/include/pcpu_aux.h:55 To: Michael Jung Cc: freebsd-current@freebsd.org, Jamie Gritton Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4PKQYg4JCPz4QJm X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2001:4860:4864::/48, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N looks like a jail problem, maintainer cc'ed On 2/19/23, Michael Jung wrote: > After upgrading from > > FreeBSD firewall.mikej.com 13.1-STABLE FreeBSD 13.1-STABLE #21 > stable/13-n253337-16603f60156e:Wed Dec 28 08:22:48 EST 2022 > mikej@firewall.mikej.com:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64 > > TO > > FreeBSD firewall.mikej.com 13.2-STABLE FreeBSD 13.2-STABLE #3 > stable/13-n254483-e0c3f2a1e296: Tue Feb 14 19:25:51 EST 2023 > mikej@firewall.mikej.com:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64 > > I had a kernel crash which can be found here. > > http://mail.mikej.com/core.txt.0 > > It has not happened again, but I'm putting it though it's normal paces. > > The only thing that was occurring which is not a normal thing for me to > is I was moving TB's worth of data between directly attached two zpools. > > Regards, > > Michael Jung > > > > > -- Mateusz Guzik From nobody Sun Feb 19 14:37:46 2023 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 4PKSpM51bVz3rF03 for ; Sun, 19 Feb 2023 14:38:19 +0000 (UTC) (envelope-from freebsd@walstatt-de.de) Received: from smtp052.goneo.de (smtp5.goneo.de [IPv6:2001:1640:5::8:30]) (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 4PKSpL2hjwz4c6W for ; Sun, 19 Feb 2023 14:38:18 +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=W6XUA6HH; spf=none (mx1.freebsd.org: domain of freebsd@walstatt-de.de has no SPF policy when checking 2001:1640:5::8:30) smtp.mailfrom=freebsd@walstatt-de.de; dmarc=none Received: from hub1.goneo.de (hub1.goneo.de [85.220.129.52]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by smtp5.goneo.de (Postfix) with ESMTPS id 0B84710A32DA; Sun, 19 Feb 2023 15:38:16 +0100 (CET) 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 (2048 bits)) (No client certificate requested) by hub1.goneo.de (Postfix) with ESMTPS id 6851C10A1E97; Sun, 19 Feb 2023 15:38:14 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=walstatt-de.de; s=DKIM001; t=1676817494; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=nn+DcUFB0pljFv5wlRI+MXfwS3xODxkLu6CGKOEOwS8=; b=W6XUA6HHlW2FgOgSPv6jVKpWUILhi9JZWC21dF/qVYH4lZWdNLJDJRTg6j2SbFwLEZK5Q8 ki15FopWUvEtI/VjQP6uYhi7q9RHlSJXrLkxDccxcIYb2LpUE1Kqi6py1I1rWZwwpBimXQ ni6/JHIdTXdqv9llc6B68MY1zXFkiBXIvvzrn0scrs2Fqe2fiqWXqw/IxfDegk22vQDJ8s lu0dFw2o1L/fD9RRTD+POmdEOjziz/TSIII6SDdps/PeQnReLSf4K2gx3mYlyJbgG9rcAh nlIRvj/Aai7esYJXuxzrkFpk4w+UWVlVru7Ke5bSpXD2wqgDp5z1a6Fui96lpA== Received: from thor.intern.walstatt.dynvpn.de (dynamic-078-054-146-144.78.54.pool.telefonica.de [78.54.146.144]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by hub1.goneo.de (Postfix) with ESMTPSA id 35F1D10A1E96; Sun, 19 Feb 2023 15:38:14 +0100 (CET) Date: Sun, 19 Feb 2023 15:37:46 +0100 From: FreeBSD User To: Rick Macklem Cc: FreeBSD CURRENT Subject: Re: CURRENT: Crash in multiuser mode while shutdown Message-ID: <20230219153813.31876247@thor.intern.walstatt.dynvpn.de> In-Reply-To: References: <20230219103807.38798427@thor.intern.walstatt.dynvpn.de> Organization: walstatt-de.de 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 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-UID: 49ce67 X-Rspamd-UID: 664557 X-Spamd-Result: default: False [-3.40 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.997]; R_DKIM_ALLOW(-0.20)[walstatt-de.de:s=DKIM001]; MIME_GOOD(-0.10)[text/plain]; RCVD_IN_DNSWL_LOW(-0.10)[2001:1640:5::8:30:from]; DKIM_TRACE(0.00)[walstatt-de.de:+]; ASN(0.00)[asn:25394, ipnet:2001:1640::/32, country:DE]; RCPT_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; FREEMAIL_TO(0.00)[gmail.com]; MIME_TRACE(0.00)[0:+]; TO_DN_ALL(0.00)[]; RCVD_COUNT_THREE(0.00)[4]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; R_SPF_NA(0.00)[no SPF record]; DMARC_NA(0.00)[walstatt-de.de]; TAGGED_RCPT(0.00)[]; HAS_ORG_HEADER(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[] X-Rspamd-Queue-Id: 4PKSpL2hjwz4c6W X-Spamd-Bar: --- X-ThisMailContainsUnwantedMimeParts: N Am Sun, 19 Feb 2023 06:19:04 -0800 Rick Macklem schrieb: > I committed a patch that would cause crashes if > the system was using jails on Feb. 11, but it was > fixed the next day. It bogusly had a prison_cleanup() > method in it. > > But if you kernel wasn't from main on about Feb. 11 > or you aren't running jails, I don't think this is it. Sources are most recent. > > It is too bad you don't have a backtrace? I need the box today, the other one is a poudriere host and can't be interrupted on short notice, I will enable debugging as I finish my work. The I hope I can provide you with a backtrace. cpu-data has been updated recently, I use this on these two IvyBridge methusalem riggs, I may disable this first and see what happens ... Regards oh > > rick > > On Sun, Feb 19, 2023 at 1:38 AM FreeBSD User wrote: > > > > Hello, > > > > most recent CURRENT crashes on shutdown from multiuser mode (singleuser mode, used after > > repairing failed FFS filesystems, is all right). The crashes go on since roughly a 1/2 week > > from now. The boxes involved are all cumtomized kernels (in most cases hard linked modules > > into kernel). Is there a known issue? > > > > Otherwise I have to reconfigure all systems for debugging an d will report aftwards more. > > > > > > Regards and thanks in advance > > Oliver > > -- > > O. Hartmann > > -- O. Hartmann From nobody Sun Feb 19 17:52:42 2023 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 4PKY6q3kQ4z3rW88 for ; Sun, 19 Feb 2023 17:52:51 +0000 (UTC) (envelope-from jamie@freebsd.org) Received: from gritton.org (gritton.org [162.220.209.3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "gritton.org", Issuer "gritton.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4PKY6q0nsvz3mRT for ; Sun, 19 Feb 2023 17:52:51 +0000 (UTC) (envelope-from jamie@freebsd.org) Authentication-Results: mx1.freebsd.org; none Received: from gritton.org ([127.0.0.3]) (authenticated bits=0) by gritton.org (8.16.1/8.16.1) with ESMTPA id 31JHqgAO069004; Sun, 19 Feb 2023 09:52:42 -0800 (PST) (envelope-from jamie@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 MIME-Version: 1.0 Date: Sun, 19 Feb 2023 09:52:42 -0800 From: James Gritton To: Mateusz Guzik Cc: Michael Jung , freebsd-current@freebsd.org Subject: Re: FreeBSD 13.2-stable crash in /usr/src/sys/amd64/include/pcpu_aux.h:55 In-Reply-To: References: <5e1ecc29-9ce3-9588-fd12-0384a6b35815@mikej.com> User-Agent: Roundcube Webmail/1.4.11 Message-ID: X-Sender: jamie@freebsd.org Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4PKY6q0nsvz3mRT X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:30247, ipnet:162.220.208.0/22, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N I'll see if I can find something. - James On 2023-02-19 04:57, Mateusz Guzik wrote: > looks like a jail problem, maintainer cc'ed > > On 2/19/23, Michael Jung wrote: >> After upgrading from >> >> FreeBSD firewall.mikej.com 13.1-STABLE FreeBSD 13.1-STABLE #21 >> stable/13-n253337-16603f60156e:Wed Dec 28 08:22:48 EST 2022 >> mikej@firewall.mikej.com:/usr/obj/usr/src/amd64.amd64/sys/GENERIC >> amd64 >> >> TO >> >> FreeBSD firewall.mikej.com 13.2-STABLE FreeBSD 13.2-STABLE #3 >> stable/13-n254483-e0c3f2a1e296: Tue Feb 14 19:25:51 EST 2023 >> mikej@firewall.mikej.com:/usr/obj/usr/src/amd64.amd64/sys/GENERIC >> amd64 >> >> I had a kernel crash which can be found here. >> >> http://mail.mikej.com/core.txt.0 >> >> It has not happened again, but I'm putting it though it's normal >> paces. >> >> The only thing that was occurring which is not a normal thing for me >> to >> is I was moving TB's worth of data between directly attached two >> zpools. >> >> Regards, >> >> Michael Jung From nobody Sun Feb 19 18:21:54 2023 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 4PKYmg6bW9z3rXq9 for ; Sun, 19 Feb 2023 18:22:11 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4PKYmg67ySz3rxb; Sun, 19 Feb 2023 18:22:11 +0000 (UTC) (envelope-from dim@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1676830931; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=N74qDXZkfdm4Qdry9mw4+l1gETfJI8mlFWh6xNsodWU=; b=TC+AYq8uo88M00eMBhAO4pm4xq2dlbWf4DrRrKZc/1a2s2n/ZluxneKkNgjfmtB2lKaEEJ Fcjfyr4rADVlPDWzeWJVhDtwiS6uVnOzSlduNaR8B66NVZMvKLUpVsOXhKQ4gKEHcdwwwA POOD9O1BUvgcR7jpiIDwvUT/57EoBb/QlYKkCto2Ahr3UXURDnSCZTMGCi+Avoe0S4AgLK 9H7RHd5xS3l8LCw6JACODZbeQVKtdDDKF3nsFbwzc0CVy+OYpjN9X080rILeI7Q7jWq/Np Ic5SFZEiRDzAbR24yTjF8f3VZ7OA4kikXnWvsbG9MgrLSW1ceDoDcQTiwXliuA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1676830931; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=N74qDXZkfdm4Qdry9mw4+l1gETfJI8mlFWh6xNsodWU=; b=Ii4wpSpONmf0UrE6jRGvlf/ln6QhWdrB916lXlmL0q9FQWg1yzv8oG14OvZoRPEm+AnrEq P+aJrVUHJbMYoTtdoJO0CWrok4olPF8d2ldNGccLyfh77wNNxwIqDCeK6pdQZAcPXynGCA xBM3RwYBRRFjKflv7y9g6bWxnMj6ywumaWQLQblbbgZvSTaN4X0ZVnNpffhGgUGL+PlFQd 7fyzZyrmoYWJ7djps1K5I5bMMmKJIS6QxaGRfl4b+gIlr4f1kGjLTOe/nEZ11ZrVWocpyw eIGXjUAQgDW28gteA6kEoSTlie3jjQpvnJ9bk/Gc9b4/fYrT7TOp0baY6ZCtBA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1676830931; a=rsa-sha256; cv=none; b=eLHM4ORnNZr5sWEY7dxuWtYMKqggNm9ABYQvwNYAFMGiMLlTicbWZZi/BHsXsjtwA925dY 4Pd7nEFJLjTTLR7u1b8C/vCRdwR0UQ4eYsgWXGNWT6yHREgeNvZRLPSgTne+5NlPV3RcUJ YZSTfUuSD2Me0aUaCgj+Is1mHtO+1xZ3diRZrnGlOy3J1HkQirMhI6TfN41gSsjUylctt5 HqvDTELPGwTNs9klFGcYdLZW6jWBfSVDW0q9QKCDEw7qykwWjbiFQEkWEpMjepSegZWUYm vGHfJmd411En3eKs37uUQJZIsyhABkyD4J3t+q1sW3SkteuAo22LPzSndUyDhQ== Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) (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 "tensor.andric.com", Issuer "R3" (verified OK)) (Authenticated sender: dim) by smtp.freebsd.org (Postfix) with ESMTPSA id 4PKYmg482szjjy; Sun, 19 Feb 2023 18:22:11 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from smtpclient.apple (longrow.home.andric.com [192.168.0.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 32B4C360DB; Sun, 19 Feb 2023 19:22:10 +0100 (CET) Content-Type: multipart/signed; boundary="Apple-Mail=_EACB1B30-8690-4903-AE71-997401390EDA"; protocol="application/pgp-signature"; micalg=pgp-sha1 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 Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.400.51.1.1\)) Subject: Re: core dump in ld during buildworld From: Dimitry Andric In-Reply-To: Date: Sun, 19 Feb 2023 19:21:54 +0100 Cc: freebsd-current@freebsd.org Message-Id: <148DE8E6-E1F2-4132-992A-1A2B9D438B63@FreeBSD.org> References: <25B4B3AD-3791-44D0-9FFA-7F1C2A9E82B9@FreeBSD.org> To: sgk@troutmask.apl.washington.edu X-Mailer: Apple Mail (2.3731.400.51.1.1) X-ThisMailContainsUnwantedMimeParts: N --Apple-Mail=_EACB1B30-8690-4903-AE71-997401390EDA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 19 Feb 2023, at 06:15, Steve Kargl = wrote: >=20 > On Sat, Feb 18, 2023 at 04:57:45PM -0800, Steve Kargl wrote: >>>=20 >>> At that point it is still using the system compiler and linker, and = it >>> seems that the latter is lld. Do you know which version it is? >>>=20 >>=20 >> Good question. Unfortunate ident(1) is useless in a git world. >>=20 >> % ll /usr/bin/ld.lld >> -r-xr-xr-x 1 root wheel - 41754432 Jan 15 12:03 /usr/bin/ld.lld >>=20 >> This was built from source from Jan 15 2023. >>=20 >> % /usr/bin/ld.lld --version >> LLD 14.0.5 (FreeBSD llvmorg-14.0.5-0-gc12386ae247c-1400004) = (compatible with GNU linkers) >>=20 >=20 > So, is there some way to rebild only ld.lld and install a new loader? >=20 > % cd /usr/src/usr.bin/clang/lld > % make depend > llvm-tblgen -gen-opt-parser-defs -I = /usr/src/contrib/llvm-project/llvm/include -d Options.inc.d -o = Options.inc /usr/src/contrib/llvm-project/lld/ELF/Options.td > make: exec(llvm-tblgen) failed (No such file or directory) > *** Error code 1 >=20 > How to I fix this? Assuming llvm-tblgen has already been built (it's a bootstrap-tool), and you have a regular setup, it should be in: = /usr/obj/usr/src/amd64.amd64/tmp/obj-tools/usr.bin/clang/llvm-tblgen/llvm-= tblgen You could try setting LLVM_TBLGEN to that path, then first build libllvm just to be sure, then usr.bin/clang/lld: export = LLVM_TBLGEN=3D/usr/obj/usr/src/amd64.amd64/tmp/obj-tools/usr.bin/clang/llv= m-tblgen/llvm-tblgen make -C /usr/src/lib/clang/libllvm make -C /usr/src/usr.bin/clang/lld If that works, you can run make install from usr.bin/clang/lld. -Dimitry --Apple-Mail=_EACB1B30-8690-4903-AE71-997401390EDA 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----- Version: GnuPG/MacGPG2 v2.2 iF0EARECAB0WIQR6tGLSzjX8bUI5T82wXqMKLiCWowUCY/JowgAKCRCwXqMKLiCW o33SAKCctMa74JkhE+Id3cbKmfoFNDT3sgCg2slzcgTf1YN5LLsG7mjXjRKBoBM= =z8yc -----END PGP SIGNATURE----- --Apple-Mail=_EACB1B30-8690-4903-AE71-997401390EDA-- From nobody Mon Feb 20 08:23:53 2023 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 4PKwS173Hrz3sBLs for ; Mon, 20 Feb 2023 08:24:01 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (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 "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4PKwS14Qhtz472W; Mon, 20 Feb 2023 08:24:01 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Authentication-Results: mx1.freebsd.org; none Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.17.1/8.17.1) with ESMTPS id 31K8NrIu097500 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Mon, 20 Feb 2023 00:23:53 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.17.1/8.17.1/Submit) id 31K8NrUA097499; Mon, 20 Feb 2023 00:23:53 -0800 (PST) (envelope-from sgk) Date: Mon, 20 Feb 2023 00:23:53 -0800 From: Steve Kargl To: Dimitry Andric Cc: freebsd-current@freebsd.org Subject: Re: core dump in ld during buildworld Message-ID: Reply-To: sgk@troutmask.apl.washington.edu References: <25B4B3AD-3791-44D0-9FFA-7F1C2A9E82B9@FreeBSD.org> <148DE8E6-E1F2-4132-992A-1A2B9D438B63@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 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <148DE8E6-E1F2-4132-992A-1A2B9D438B63@FreeBSD.org> X-Rspamd-Queue-Id: 4PKwS14Qhtz472W X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:73, ipnet:128.95.0.0/16, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N On Sun, Feb 19, 2023 at 07:21:54PM +0100, Dimitry Andric wrote: > On 19 Feb 2023, at 06:15, Steve Kargl wrote: > > > > On Sat, Feb 18, 2023 at 04:57:45PM -0800, Steve Kargl wrote: > >>> > >>> At that point it is still using the system compiler and linker, and it > >>> seems that the latter is lld. Do you know which version it is? > >>> > >> > >> Good question. Unfortunate ident(1) is useless in a git world. > >> > >> % ll /usr/bin/ld.lld > >> -r-xr-xr-x 1 root wheel - 41754432 Jan 15 12:03 /usr/bin/ld.lld > >> > >> This was built from source from Jan 15 2023. > >> > >> % /usr/bin/ld.lld --version > >> LLD 14.0.5 (FreeBSD llvmorg-14.0.5-0-gc12386ae247c-1400004) (compatible with GNU linkers) > >> > > > > So, is there some way to rebild only ld.lld and install a new loader? > > > > % cd /usr/src/usr.bin/clang/lld > > % make depend > > llvm-tblgen -gen-opt-parser-defs -I /usr/src/contrib/llvm-project/llvm/include -d Options.inc.d -o Options.inc /usr/src/contrib/llvm-project/lld/ELF/Options.td > > make: exec(llvm-tblgen) failed (No such file or directory) > > *** Error code 1 > > > > How to I fix this? > > Assuming llvm-tblgen has already been built (it's a bootstrap-tool), > and you have a regular setup, it should be in: > > /usr/obj/usr/src/amd64.amd64/tmp/obj-tools/usr.bin/clang/llvm-tblgen/llvm-tblgen > > You could try setting LLVM_TBLGEN to that path, then first build libllvm > just to be sure, then usr.bin/clang/lld: > > export LLVM_TBLGEN=/usr/obj/usr/src/amd64.amd64/tmp/obj-tools/usr.bin/clang/llvm-tblgen/llvm-tblgen > make -C /usr/src/lib/clang/libllvm > make -C /usr/src/usr.bin/clang/lld > > If that works, you can run make install from usr.bin/clang/lld. > Thanks for the hints. The above got me past the segfault in ld.ldd. I now have an error about libdwarf.a being truncated and extended beyond some limit while building nm. I'm simply do 'make -k buildworld' now to see if anything is running south. -- Steve From nobody Mon Feb 20 08:40:36 2023 X-Original-To: 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 4PKwqJ0rdyz3sCZh for ; Mon, 20 Feb 2023 08:40:44 +0000 (UTC) (envelope-from jbtakk@iherebuywisely.com) Received: from mailtransmit05.runbox.com (mailtransmit05.runbox.com [IPv6:2a0c:5a00:149::26]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4PKwqH2Qrxz4Cv7 for ; Mon, 20 Feb 2023 08:40:43 +0000 (UTC) (envelope-from jbtakk@iherebuywisely.com) Authentication-Results: mx1.freebsd.org; dkim=none ("invalid DKIM record") header.d=iherebuywisely.com header.s=selector1 header.b=fFMr3W+k; spf=pass (mx1.freebsd.org: domain of jbtakk@iherebuywisely.com designates 2a0c:5a00:149::26 as permitted sender) smtp.mailfrom=jbtakk@iherebuywisely.com; dmarc=none Received: from mailtransmit02.runbox ([10.9.9.162] helo=aibo.runbox.com) by mailtransmit05.runbox.com with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.93) (envelope-from ) id 1pU1iw-00AfPq-8e for current@freebsd.org; Mon, 20 Feb 2023 09:40:38 +0100 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=iherebuywisely.com; s=selector1; h=Message-Id:In-Reply-To:Date:Subject:CC: To:From:MIME-Version:Content-Transfer-Encoding:Content-Type; bh=cJRjozcCswi7tJLkzL9zDgqj7OE6Sp5qZGKeFudWASY=; b=fFMr3W+kLb+PGKwtJx92Ov1o6i DGplHzsZC2gv9AHKgs5IoT9DG+WifWeNhjSNU3RFQt4Ks5Ii55wdYb/mbTLkNmdL5Y3OS8nv+kmDi 07E9/TXb8Buid3bY1rMw8UH4QcrWR0urT38IA9rzR3L9fyeBcpRHYvGOKk7uVxTGLJFb5Fwx8VeOR VnrSCSqYKj8bJSdcas5XarC6fcK7IAVh721JAr15YHrR0cKIQzcy9O56BPLe0s0djRR2WmFZ9Ka+h 0oHAVTDxlUX57CbGTMRgMdg2wuqtYL3TW5Nfsm+0fN794a09y4Tm79Pa+b+rnoSw3+/L6gRt+BL52 XW4VjBUQ==; Received: from [10.9.9.127] (helo=rmmprod05.runbox) by mailtransmit02.runbox with esmtp (Exim 4.86_2) (envelope-from ) id 1pU1iu-0008IH-S0; Mon, 20 Feb 2023 09:40:37 +0100 Received: from mail by rmmprod05.runbox with local (Exim 4.86_2) (envelope-from ) id 1pU1iu-0006DF-QZ; Mon, 20 Feb 2023 09:40:36 +0100 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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 MIME-Version: 1.0 Received: from [Authenticated alias (650894)] by runbox.com with http (RMM6); Mon, 20 Feb 2023 08:40:36 GMT From: "Jeffrey Bouquet" To: "Jeffrey Bouquet" CC: "current" Subject: Re: buildworld failure Date: Mon, 20 Feb 2023 00:40:36 -0800 (PST) X-RMM-Aliasid: 650894 X-Mailer: RMM6 In-Reply-To: Message-Id: X-Spamd-Result: default: False [-3.20 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.98)[-0.976]; NEURAL_HAM_LONG(-0.82)[-0.819]; R_SPF_ALLOW(-0.20)[+ip6:2a0c:5a00:149::26]; MIME_GOOD(-0.10)[text/plain]; RCVD_IN_DNSWL_LOW(-0.10)[2a0c:5a00:149::26:from]; RCVD_TLS_LAST(0.00)[]; R_DKIM_PERMFAIL(0.00)[iherebuywisely.com:s=selector1]; MIME_TRACE(0.00)[0:+]; MLMMJ_DEST(0.00)[current@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; TO_DN_ALL(0.00)[]; ASN(0.00)[asn:50304, ipnet:2a0c:5a00::/29, country:NO]; RCVD_COUNT_FIVE(0.00)[5]; DKIM_TRACE(0.00)[iherebuywisely.com:~]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DMARC_NA(0.00)[iherebuywisely.com]; ARC_NA(0.00)[] X-Rspamd-Queue-Id: 4PKwqH2Qrxz4Cv7 X-Spamd-Bar: --- X-ThisMailContainsUnwantedMimeParts: N On Sat, 18 Feb 2023 13:28:58 -0800 (PST), "Jeffrey Bouquet" wrote: >=20 >=20 > On Sat, 18 Feb 2023 00:33:11 -0800 (PST), "Jeffrey Bouquet" wrote: >=20 > > Building /usr/obj/usr/src/amd64.amd64/tools/build/test-includes/sys_bit= count.c > > Building /usr/obj/usr/src/amd64.amd64/tools/build/test-includes/sys_bit= count.o > > sys_bitcount.c:1:10: fatal error: 'sys/bitcount.h' file not found > > #include > > ^~~~~~~~~~~~~~~~ > > 1 error generated. > > *** Error code 1 > >=20 > > Stop. > > make[3]: stopped in /usr/src/tools/build/test-includes > > .ERROR_TARGET=3D'sys_bitcount.o' > > .ERROR_META_FILE=3D'/usr/obj/usr/src/amd64.amd64/tools/build/test-inclu= des/sys_bitcount.o.meta' > > .MAKE.LEVEL=3D'3' > > MAKEFILE=3D'' > > .MAKE.MODE=3D'meta missing-filemon=3Dyes missing-meta=3Dyes silent=3Dye= s verbose' > > _ERROR_CMD=3D'/usr/local/bin/clang14 -O2 -pipe -fno-common -g -gz=3D= zlib -std=3Dgnu99 -Wno-format-zero-length -nobuiltininc -idirafter /usr/loc= al/llvm14/lib/clang/14.0.6/include -fstack-protector-strong -Wsystem-header= s -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototype= s -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-st= rings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -= Wnested-externs -Wold-style-definition -Wno-pointer-sign -Wdate-time -Wmiss= ing-variable-declarations -Wthread-safety -Wno-empty-body -Wno-string-plus-= int -Wno-unused-const-variable -Wno-error=3Dunused-but-set-variable -Qunus= ed-arguments -c sys_bitcount.c -o sys_bitcount.o; ;' > > .CURDIR=3D'/usr/src/tools/build/test-includes' > > .MAKE=3D'make' > > .OBJDIR=3D'/usr/obj/usr/src/amd64.amd64/tools/build/test-includes' > > .TARGETS=3D'test-includes' > > DESTDIR=3D'/usr/obj/usr/src/amd64.amd64/tmp' > > LD_LIBRARY_PATH=3D'' > > MACHINE=3D'amd64' > > MACHINE_ARCH=3D'amd64' > > MAKEOBJDIRPREFIX=3D'' > > MAKESYSPATH=3D'/usr/src/share/mk' > > MAKE_VERSION=3D'20220208' > > PATH=3D'/usr/obj/usr/src/amd64.amd64/tmp/bin:/usr/obj/usr/src/amd64.amd= 64/tmp/usr/sbin:/usr/obj/usr/src/amd64.amd64/tmp/usr/bin:/usr/obj/usr/src/a= md64.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.amd6= 4/tmp/legacy/usr/libexec::/usr/obj/usr/src/amd64.amd64/tmp/bin:/usr/obj/usr= /src/amd64.amd64/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/t= mp/legacy/usr/bin:/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' > > SRCTOP=3D'/usr/src' > > OBJTOP=3D'/usr/obj/usr/src/amd64.amd64 > > ..................................... > >=20 > > Anyone see/know anything causing this error?=20 > > Also, the buildworld command most likely to build the most amd64 compon= ents from scratch?=20 >=20 >=20 > seems "make hier" fixed it partially > then WITHOUT_OFED=3Dyes in src.conf. maybe fixed, maybe not.=20 Not fixed. question 1.=20=20 While building, it fails in some subtree.=20 I change to that location and "make" which succeeds back in buildworld, stage 4.4, it then fails at the same place despite the "make" success. also, it re attempts to build in places I've WITHOUT_ in src.conf BOTH situations appear concurrently during the build, which halts, confusin= g me as to which condition causes the failure. Any workaround or fix? Seems the system is a hybrid of CURRENT and of 13-stable now, running witho= ut issues otherwise. leading to question 2. Ideally, I could overcome the buildworld failure by sequentially installing= all parts of the buildworld which have SO FAR not failed? and where would I find the sequence of locations from which to do a "make" "make install" mimicing an installworld DURING buildworld, as if each part of=20 buildworld after success coud be installed, leading to a greater probability that the entire buildworld could finish without error and to the likelihood also that an installworld would not fail due to most of its parts already having been completed. ... might as well put this question in also. ............... 3... there is pending a UFS2 packagebase somewhere still in code review or = beta? How might I use that to overcome this issue and install CURRENT if packages= ets were available?=20 thanks in advance.=20 Jeff=20 From nobody Tue Feb 21 05:23:48 2023 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 4PLSQt3nzdz3t3VF for ; Tue, 21 Feb 2023 05:24:54 +0000 (UTC) (envelope-from sjg@juniper.net) Received: from mx0b-00273201.pphosted.com (mx0b-00273201.pphosted.com [67.231.152.164]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.pphosted.com", Issuer "Thawte RSA CA 2018" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4PLSQs48lRz3JDb; Tue, 21 Feb 2023 05:24:53 +0000 (UTC) (envelope-from sjg@juniper.net) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=juniper.net header.s=PPS1017 header.b=JPoTPRpO; dkim=pass header.d=juniper.net header.s=selector1 header.b=ekPGjUHc; spf=pass (mx1.freebsd.org: domain of sjg@juniper.net designates 67.231.152.164 as permitted sender) smtp.mailfrom=sjg@juniper.net; dmarc=pass (policy=reject) header.from=juniper.net; arc=pass ("microsoft.com:s=arcselector9901:i=1") Received: from pps.filterd (m0108163.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 31L2iouG023108; Mon, 20 Feb 2023 21:24:50 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=to : cc : subject : in-reply-to : references : from : mime-version : content-type : content-id : date : message-id; s=PPS1017; bh=M/BrRZ9OhlwNUUe2cv4PsoxobFJ9qNFMCSfaHyoXydI=; b=JPoTPRpO7fTQvi5mGCA4ClF5mgL8+Yw/iNLqyCzO8gVYz02ikclQIFmdY0eWEOCbIfas 2zT2D5lz0Og0EKCFE53Ml+i12inIBjVoXyAfC78ZAUakRecYz1qPbi8auWt6J+t+XGhc XXFdwMoiPbQwQJI17jTcZXBOjCr7dJITZHdM7JJhxOwK7FhBo0g9y5UUjrTm6BrH5HfP gyJVGaDsHSIMDlbTbGXjOL1R5ASr++reUydXnnSo83XiLwiB4DQHS+eJJgLBMo4CXzFG BVRsySH4game/+JN3z9Jcg1ObNrsKpfe5KfTXiaHUSCGUrc7H7dzmcxMzTwTQus2D0Bc OQ== Received: from bl0pr02cu005-vft-obe.outbound.protection.outlook.com (mail-eastusazlp17012028.outbound.protection.outlook.com [40.93.11.28]) by mx0b-00273201.pphosted.com (PPS) with ESMTPS id 3nttsucsj4-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 20 Feb 2023 21:24:50 -0800 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=XbdOYA9IfbvHQY7K98J+CYLtE62IfkHKGI/swdg0nHjSIIvm/fh47/GCYtiRgWN95bGNYMM1odbvUz9KXFGhWi/FjQLs6JAxoAZroVDzcVPMZeDFWFfJ/WPsO4uDc1rXHcRNf+sm+ik/rNwzV7/wugwxLQWgBFwAaqsLllQ40aBVpIeOx2V8ca785y6oHCavaypCs7eEoepFCFIB/zajngJq71PVgF3rduALMt26KDsXGts5PbALKf819qONw67Uh7bOpMis4KdggcrlHNGzRSU9ikoqDIVD/NkbxeksISm45DeRAxIKXtLW3O8g8LaEDgRO8zY+0q47ANWdoGboAg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=M/BrRZ9OhlwNUUe2cv4PsoxobFJ9qNFMCSfaHyoXydI=; b=gIDZnsvcZI3HWxpccCY8XEtiVECCE/oanuE3YbX7vSjhyyKlFEOaqMbW81hqEGKnFpxE103lbqRqTKBvrhxXgFXXyFYMu00e8XM0PGOAWE7BZIq+Fne9TX0o0+usYWF6cvL2Bez+RgbfDj0WTHHrkrgPZXoXlPDFUbIVbeKKtO89Zgh1kEPnlwdkw0xgUfjj6Sd37Au/WzF6QCYxCgJXQA4IK+UcTdvcLiFaokyIqiDfpxrQaqKDGxTiA/Ikx0coCwkVJ04bQtjZGfWKPY3yYGiEf64zeRF0rncBe/gGX+rUq0G2j46CVsQWH4kbQKjvlFmB3CUfOGJrKQ3gsCeo+Q== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=softfail (sender ip is 66.129.239.15) smtp.rcpttodomain=freebsd.org smtp.mailfrom=juniper.net; dmarc=fail (p=reject sp=reject pct=100) action=oreject header.from=juniper.net; dkim=none (message not signed); arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=M/BrRZ9OhlwNUUe2cv4PsoxobFJ9qNFMCSfaHyoXydI=; b=ekPGjUHcuKGQ9ziNeFJ/E4+h3u1PYPnEw/wbPXhM3EhITRQKUv88Y9O3ggPTmhAi13rfBKt8jpQdQE6cQD0CrOl9f0OYLhmuuoDOjg8PFEpdJzz0tJWAL1H3F+pWVzec655BpQRFV0WTEeS/UloROgY5YPvrvNVmzlzPuVKxWkU= Received: from MW4PR04CA0325.namprd04.prod.outlook.com (2603:10b6:303:82::30) by MWHPR05MB3024.namprd05.prod.outlook.com (2603:10b6:300:60::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6111.21; Tue, 21 Feb 2023 05:24:46 +0000 Received: from MW2NAM12FT116.eop-nam12.prod.protection.outlook.com (2603:10b6:303:82:cafe::c8) by MW4PR04CA0325.outlook.office365.com (2603:10b6:303:82::30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6111.20 via Frontend Transport; Tue, 21 Feb 2023 05:24:45 +0000 X-MS-Exchange-Authentication-Results: spf=softfail (sender IP is 66.129.239.15) smtp.mailfrom=juniper.net; dkim=none (message not signed) header.d=none;dmarc=fail action=oreject header.from=juniper.net; Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.15 as permitted sender) Received: from p-exchfe-eqx-02.jnpr.net (66.129.239.15) by MW2NAM12FT116.mail.protection.outlook.com (10.13.181.135) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6134.17 via Frontend Transport; Tue, 21 Feb 2023 05:24:45 +0000 Received: from p-exchbe-eqx-02.jnpr.net (10.104.9.15) by p-exchfe-eqx-02.jnpr.net (10.104.9.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.30; Mon, 20 Feb 2023 23:24:45 -0600 Received: from p-mailhub01.juniper.net (10.104.20.6) by p-exchbe-eqx-02.jnpr.net (10.104.9.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.30 via Frontend Transport; Mon, 20 Feb 2023 23:24:45 -0600 Received: from kaos.jnpr.net (kaos.jnpr.net [172.23.255.201]) by p-mailhub01.juniper.net (8.14.4/8.11.3) with ESMTP id 31L5OivZ018152; Mon, 20 Feb 2023 21:24:44 -0800 (envelope-from sjg@juniper.net) Received: by kaos.jnpr.net (Postfix, from userid 1377) id 657B91FDF5; Mon, 20 Feb 2023 21:23:48 -0800 (PST) Received: from kaos.jnpr.net (localhost [127.0.0.1]) by kaos.jnpr.net (Postfix) with ESMTP id 631BE2001C; Mon, 20 Feb 2023 21:23:48 -0800 (PST) To: Warner Losh CC: Gordon Bergling , FreeBSD Current , Subject: Re: Build breakage with WITH_BEARSSL=1 In-Reply-To: References: Comments: In-reply-to: Warner Losh message dated "Sat, 18 Feb 2023 23:55:18 -0700." From: "Simon J. Gerraty" X-Mailer: MH-E 8.6+git; nmh 1.7.1; GNU Emacs 28.1 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 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <2518.1676957028.1@kaos.jnpr.net> Date: Mon, 20 Feb 2023 21:23:48 -0800 Message-ID: <7363.1676957028@kaos.jnpr.net> X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: MW2NAM12FT116:EE_|MWHPR05MB3024:EE_ X-MS-Office365-Filtering-Correlation-Id: 8aa80978-652d-4fac-6070-08db13cbf1b8 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: N9oNv4223d5ElrqPEp3ljO+wX5pxnkkYT5dUke0fsi+3dAa5q1QAlERUWgmIK/cFYMsDFRT1UtUxErlLXkRH+BJ3fAwayK0eDmzpJa8ohk4chODlxfiFm+0h9ncnyocLj+nOR4Xyrbi3yyWGq4nNEw4rcFWy3miSS8i+Ob8OX3qGm6xmz6hgC1mtVWkgDklYfp6M4m8Lue9GvMXdoRy1diIdnO1y16xT6GYe2gPn1p4cJgRgwZHvFyTb7NRaJrw9Vw290hPt6putwnuYz/JuiNw9WJvIie6B14XTf6a71KAIwyj2RnmKg/RFR1VNoZoQGNHWA6IcjyiKdqc54As+tYJo1gqan1+LFGXC5ruqzapNxMGc65vauIs9RWiV+aHOHNB11TTpW/JaNpDzX5k8A1DOAVk+8GwDJgCZD2g6wGwky6UNwyiqvncXkjBRZAWj2YU/S6GMnGuR2yKOEcseoTTApwwC887VuRMMAj45mPtvAtqJr945GZGNWEHzLKKEaeba6FD1RTtslEflTIiaPnYFwHEUFnVuGSUl1D8JHocPJPjpTsMApa5xoKdblVWPjV0l4Jl7xC3kP1RyoFG6o7zvgnm1p5d0ZXWa7qBYf2yOgT4UpIFNBtPAFnNczmZOO6dgjfKdG6n+nEbacSrxxnG8Jgmu8z+smu16DV9v/zBTKmRNrRthm6jDG5p3mGhnRvTh31lEQIQeiC8Q7aBOVKyj8Zhyjafx6H7x6SWIRLCWxOMRwYCnI9+FFaoi1AQ+qk+PEnYM5MmCfbq9a2U2Lg== X-Forefront-Antispam-Report: CIP:66.129.239.15;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:p-exchfe-eqx-02.jnpr.net;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230025)(4636009)(396003)(39860400002)(376002)(136003)(346002)(451199018)(46966006)(36840700001)(40470700004)(6916009)(4326008)(70206006)(70586007)(8676002)(478600001)(86362001)(7126003)(558084003)(40460700003)(336012)(7696005)(107886003)(40480700001)(26005)(9686003)(4270600006)(6266002)(55016003)(186003)(54906003)(47076005)(83380400001)(316002)(81166007)(82740400003)(8936002)(356005)(5660300002)(36860700001)(41300700001)(82310400005)(2906002)(36900700001);DIR:OUT;SFP:1102; X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 21 Feb 2023 05:24:45.7269 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 8aa80978-652d-4fac-6070-08db13cbf1b8 X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4;Ip=[66.129.239.15];Helo=[p-exchfe-eqx-02.jnpr.net] X-MS-Exchange-CrossTenant-AuthSource: MW2NAM12FT116.eop-nam12.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR05MB3024 X-Proofpoint-ORIG-GUID: 5g2p26ymcaHmBXSc2UvgCNw2E_mvYfVY X-Proofpoint-GUID: 5g2p26ymcaHmBXSc2UvgCNw2E_mvYfVY X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.219,Aquarius:18.0.930,Hydra:6.0.562,FMLib:17.11.170.22 definitions=2023-02-21_02,2023-02-20_02,2023-02-09_01 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 mlxscore=0 malwarescore=0 mlxlogscore=370 phishscore=0 bulkscore=0 spamscore=0 lowpriorityscore=0 clxscore=1015 priorityscore=1501 impostorscore=0 adultscore=0 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2212070000 definitions=main-2302210047 X-Spamd-Result: default: False [-5.10 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; ARC_ALLOW(-1.00)[microsoft.com:s=arcselector9901:i=1]; NEURAL_HAM_SHORT(-1.00)[-0.998]; DMARC_POLICY_ALLOW(-0.50)[juniper.net,reject]; R_DKIM_ALLOW(-0.20)[juniper.net:s=PPS1017,juniper.net:s=selector1]; R_SPF_ALLOW(-0.20)[+ip4:67.231.152.164]; MIME_GOOD(-0.10)[text/plain]; RCVD_IN_DNSWL_LOW(-0.10)[67.231.152.164:from]; RCPT_COUNT_THREE(0.00)[4]; MIME_TRACE(0.00)[0:+]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:22843, ipnet:67.231.152.0/24, country:US]; TO_DN_SOME(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; RCVD_IN_DNSWL_NONE(0.00)[40.93.11.28:received]; RCVD_COUNT_SEVEN(0.00)[11]; FREEFALL_USER(0.00)[sjg]; DKIM_TRACE(0.00)[juniper.net:+]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[] X-Rspamd-Queue-Id: 4PLSQs48lRz3JDb X-Spamd-Bar: ----- X-ThisMailContainsUnwantedMimeParts: N This has been fixed upstream, I'll look at importing an update. From nobody Tue Feb 21 21:31:37 2023 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 4PLstk1SqQz3tFrQ for ; Tue, 21 Feb 2023 21:31:58 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic314-20.consmr.mail.gq1.yahoo.com (sonic314-20.consmr.mail.gq1.yahoo.com [98.137.69.83]) (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 4PLstj1Yb6z4H2Q for ; Tue, 21 Feb 2023 21:31:57 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=MzVam4n8; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.83 as permitted sender) smtp.mailfrom=marklmi@yahoo.com; dmarc=pass (policy=reject) header.from=yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1677015115; bh=FzE1I31FSnydEYZ21zzULxNRPUuG7CpqKVpSQ6RsRig=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=MzVam4n86fSy/D3PueFb/cdq94gEeghKXXRWDdxaVDqNiog+N2l7k1WfwoTXS0bLAJuJM3VnnwgLMPh0ej4LWAPekO1hX3HBD7eyIoekhZHIlOayT7uNA8GwgBGhCfbW/M3Sq/bqGpsd8FYav/y76tZJFIr/fTAsMbLEOPXwp2ttpZXhHu56btw+k8rI7DItqj7E9or9SSeAzQLrjELMogJr0JQgKJNxIDAlGERidsUEoLKrV5wcV0xYnT4M5sEcLHeyC9KvQM1zXahNMJtRHQlEyI7YjplaUXlK6JDjAJ/frs0N5UpjL00w83qmjmjAl9gBilsuYcOW+KOhYRVetw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1677015115; bh=Jt39m2N7oBPK0UNuxj2uCIUSVa3LrmYuJPuxzMesTaN=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=oH6BKISZPI2/18V/2SjQjSkXKE2VZSwStJ4hIxp+rihtoZIFZTdlHVYtNxydLppdWltz0TsliljubsFUFCaFcbCgou6B8JHdh4NblMXOSdA9SYcZHdtHK98sYZyciTc1gqLwxbaRr/nYs2PXhW69cMqhpe0MzWJNUz1N2/Qw5rAvq2UwNzpM9towsz+5zRzKz8HA8r0z+iVArRqffR3Tza4jH9OWtOMf2sFFpWD2L6mn4OiBJLqvYkxVr//3tx1hUzmc8oNiiwYG5/iBUsVejJILARxSmrPOocaXjsKZeFF6WAMHvE0vT7EXgyo7WkOvxX/xxuLOsr9jkKwoX8lUsg== X-YMail-OSG: lf8hBusVM1kYpZ7HvZiLJqbXMkvoWvv.ZRtklZ_uN17yzDUoWl.4H_l78GRyWW2 kcIOqAOghSZtt.hVgMldVvA3Q_I4L6V1nSoXluB9n7YuUQ6WBTR1LKWkzTF8NwGaF7jXTMjgbosf iiwlN9O64UpHESMiqgvgxytIjfgffmqzXH0IomLV6EnnDuzhnq4SVVuoIF4QDNI2zrryJRAC3PFZ kKQPKahFT827lScefhcB6xcEbQkv5s2H81SrWta2gOufe730qQZ41nQ3psnUUzHerNf3Csd.BxEO aTCkXkmWUp2v1_W6JSZE8kPHVHzzOscd4GVjWbMy_FwbLyt9lvkf1XClNnr_bOMve63.FTOoAAT2 nGg0eGjoc9SpqA4VrAEKchKYBuvZffDTpdVJV_XRCXvyicKVT780HgJJ7y.KlQTaBE97wb3IUydg DJW8MJ8Q2rk5JE4DO5Jt.sc08vGGNpHN7_P70o4ipKEKs5IHo0FAMEu2W.hzPCwfry_N3vfg5zpX Jsu_Yk1uNz4BnsJspt4YFjWdUbqwf4lgY0z8nu5_VP3MyeNZUVgfMbQFQ4aPn5s6NTPRxpeSjeGu BVINg0QYdh4.szix.yotkKgOskm2RbVCADLKdFHkUlezx8Oxa_D5JcdeotoXk3vcRor5_T2qQTjg Cwe7D8Lx7Or9Rvob_7EVG0f5Jn9nE0y6FlS1NBzahNin217dexZfX9YQwQGRooCgCXe95MCb6bBs UMursr5L5ptQZ3wi2Br8Y_Ih99lGLKOmB5DCTBut7N.SO0cyoSxoAp1qkxErGMndthRWlKNjjhxz J3BNi6F.iJUzwwnYYzqOsr4xQU1kNzeVNXofQeIyV3i5ZKym9Vx7u3JTPYHCnvuwCMKjQBZAizwY e9RLphcGQ56toLEFNj7jy_xjZx.Qs4p94qBASnbGPHP2__eYTdfOl_LMDZmv6twYBJ.8cllnzrrq FTrwDdGg0yqk8hiTxAOUstKZL4XGsv_uj9Y8aVkiF54okPQq7BWrrYPfFVsCeJli5Z5COfv01TGo Vgf_1yh2MWD1Qva3kVtaIeiIMzY.nMisGUwgs75TTmnlAlB6NU7AgcI2RRR0ogAkyh6WbDEuCW3N Y10kxXM2g7lEVBZVHU4tfmygUhisVjPUTcinP99g8Xi4dnTrglCvkxPYIXIOT62i2evUyU2MOFtG 5XnpZjbGuKfjhZatwOmScWh1ra6NzawiAPfUfwdb9x4UNG7IHkTScCeiseO6uymed4g7IH..GfPt fUjkJ2ABNqal94dKh4Tkff9_E2iXzEW4c7Sauq1mZL_s.7vsYCeBSdTpfmvr4h6MOKFtTdoQ5M.M JcCuG_KdiuYuad7RZyqzZbjn8wiHxRNQywM98LjqnHz5XCnr39sz2pEwMz2EDuA7PKMB_4IYESDK WAO4f1DZjN_lRkMHm2h92jjFhYdfz_mg8VrXv7mCwj9vE9SVCTMDYqBkiBrPT8L.xPWo4LjrknH1 jravLYwJzACS7JyBuppRYw6yULgfxWl27mQ2_kQLPc8XZzmZZFjK92nA.DCeAJ3wk1W85GkNiND6 htyd2BR489IS3r0IPGFNLTCdg4hzl5iJCK31MgCAQbfG7nxYNZU_TyF7BBxnw0s3JGd9lUON3D9D RR3tMb2IQZdkKbZ9DgYJf2jOqpwwAzC.Hf0jp0IWmqf4QfN79eBQDdqcX4L52qLg16DCAxGW51ZQ DW8O.QkVOCYCinCoRSMKEnnK7GT9VcMC1.VoExXcnbKhl5E5zvLbewSJGjLljasBbLl6d3jwEWNj RDQnETIEDcY7RKAt00AJk1epHpaNE7UTYcMOWRyQGpxpfIO7BvSs0qcfABYdvdqrgucEwwY6eLij VV0xyCsTtEXZepBR_sc1H45XxEZvAGpGalQSpZsGPAlalQ.Pfx6H_xC0oouxjGaO1asToXZf7TBI fXncEUpngsfi5CworD.30NhSQ23snp24FEFhivTnAgzPyWp0nRk7w9zJ8nyyouVt7rz61hXujAjG H08YuCmtTltf10iKvYqG3tj9Ntcm8i90v_O8OAHU9FW7NvQEW.0XLwPFLZ_AiNh0YLkAF92Vi6pp t5mQrAhWS_V5d6xPUsdWhU5NAWfYrHzIqei7y4N0hSVnnrJ5pO9xAamXukEQxfkqqHpZflBcuQVt mLs_1kU8z.JIXOWiIG2fBNQq3L_M95QWKnOlNIXxcKapdRsjEuXfM8CV0gIHU0V4Cvs4SvBP3xiO j7SJzkTHYifehdS28738aHmlLsqznZgUF66oHHvGAVY0SnmfYL.uG_8q4NG5c0MOCANsmXp18XA5 .HEo- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic314.consmr.mail.gq1.yahoo.com with HTTP; Tue, 21 Feb 2023 21:31:55 +0000 Received: by hermes--production-bf1-57c96c66f6-kqcsw (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 410228c329f9ac3fba9d215bc5da8fc1; Tue, 21 Feb 2023 21:31:49 +0000 (UTC) Content-Type: text/plain; charset=us-ascii 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 Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.400.51.1.1\)) Subject: Re: FYI: Why META_MODE rebuilds so much for building again after installworld (no source changes) From: Mark Millard In-Reply-To: <73088.1611797582@kaos.jnpr.net> Date: Tue, 21 Feb 2023 13:31:37 -0800 Cc: Bryan Drewery , Current FreeBSD , Peter Content-Transfer-Encoding: quoted-printable Message-Id: References: <3345EBA5-A09C-4E3F-B94D-39F57F56BDBB@yahoo.com> <73088.1611797582@kaos.jnpr.net> To: "Simon J. Gerraty" X-Mailer: Apple Mail (2.3731.400.51.1.1) X-Spamd-Result: default: False [-3.47 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.97)[-0.968]; MV_CASE(0.50)[]; 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]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; ARC_NA(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.69.83:from]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; RCVD_TLS_LAST(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@FreeBSD.org]; TO_DN_ALL(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; FREEMAIL_FROM(0.00)[yahoo.com]; MID_RHS_MATCH_FROM(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; MIME_TRACE(0.00)[0:+]; FROM_EQ_ENVFROM(0.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.69.83:from] X-Rspamd-Queue-Id: 4PLstj1Yb6z4H2Q X-Spamd-Bar: --- X-ThisMailContainsUnwantedMimeParts: N [This will be a question relative to the old material below.] On Jan 27, 2021, at 17:33, Simon J. Gerraty wrote: > Mark Millard via freebsd-current wrote: >>>> Given an already built, installed and booted system version, I've >>>> noted a big difference for META_MODE in 2 rebuild contexts (no >>>> source updates involved): >>>>=20 >>>> *) Prior buildworld buildkernel, installkernel, installworld, boot >>>> presumed before (A) and before (B) below. >=20 > Yes installworld is going to cause problems unless you tell meta mode = to > ignore everything outside of the src/obj tree. > But even that isn't enough as you note below. >=20 >>>> So I used make -dM for the commented buildworld buildkernel lines, = logging >>>> the build output and later diff'ing them. >>>>=20 >>>> Result that I noticed? Lots of lines uniquely from (B)'s case, = ending with >>>> one of: >>>>=20 >>>> file = '/usr/obj/amd64_clang/amd64.amd64/usr/fbsd/mm-src/amd64.amd64/tmp/legacy/u= sr/sbin/awk' is newer than the target... >=20 > Yes. That would be expected. > I think Bryan added some knobs to mitigate some of this. >=20 > grep -n META.*IGNORE share/mk/*mk >=20 > might be instructive. >=20 >>>> Many/most/all(?) of these seem to me to be unlikely to actually = need to >>>> contribute to what needs to be rebuilt (just based on being newer). = So >>>> the option to ignore (some of?) them could be useful in making = META_MODE >>>> builds quicker. >=20 > Yes on all counts. That's why bmake provides a number of knobs to > ignore such things. > They are listed in the man page in increasing order of expense. >=20 > One of the risks of the sort of introspection meta mode does, is = delving > too deep (like the dwarfs ;-) >=20 > The .MAKE.META.IGNORE_* and .MAKE.META.BAILIWICK variables help to > contain the potential insanity. >=20 >>> The following from one of the .meta files makes the point that rm = use >>> in the example is unlikely to be important to needing to rebuild, >>> despite it actually causing a file rebuild. Nor is the specific echo >>> command listed relevant. Only the "ar" command is: >>>=20 >>> # Meta data file = /usr/obj/amd64_clang/amd64.amd64/usr/fbsd/mm-src/amd64.amd64/lib/libc++/li= bc++.a.meta >>> CMD @echo building static c++ library >>> CMD @rm -f libc++.a >>> CMD ar -crsD libc++.a algorithm.o any.o atomic.o barrier.o bind.o >=20 >>> -- filemon acquired metadata -- >>> # filemon version 5 >>> # Target pid 22471 >>> # Start 1611359217.214996 >>> V 5 >>> E 22961 /bin/sh >>> R 22961 /etc/libmap.conf >>> R 22961 /var/run/ld-elf.so.hints >>> R 22961 /lib/libedit.so.7 >>> R 22961 /lib/libc.so.7 >>> R 22961 /lib/libncursesw.so.9 >>> R 22961 /usr/share/locale/C.UTF-8/LC_CTYPE >>> F 22961 22962 >>> E 22962 = /usr/obj/amd64_clang/amd64.amd64/usr/fbsd/mm-src/amd64.amd64/tmp/legacy/us= r/sbin/rm >=20 >>> The timestamp on . . ./tmp/legacy/usr/sbin/rm is not >>> actually relevant to if libc++.a needs to be rebuilt. >=20 > True.=20 > If there is nothing under .../tmp/legacy that should be counted you = can > just: >=20 > .MAKE.META_IGNORE_PATHS +=3D that path >=20 > which would be the cheapest option. >=20 > If however there are things that should be considered you'd have to > use a much more specific list of .MAKE.META_IGNORE_PATHS or > perhaps something like: >=20 > .MAKE.META.IGNORE_PATTERNS +=3D */rm >=20 > would ignore an rm binary regardless of where found. >=20 > worst case you might need something like: >=20 > # realpath > .MAKE.META.IGNORE_FILTER +=3D tA > # ignore anything here > .MAKE.META.IGNORE_FILTER +=3D N*/tmp/legacy/usr/bin/* >=20 > Unlike .MAKE.META.IGNORE_PATTERNS which is a list of patterns to match > the goal with .MAKE.META.IGNORE_FILTER is to reduced to an empty = string > paths to be ignored. >=20 >>> Of course, the structure also point out the judgment >>> is specific to understanding the sequence of CMD's >>> listed above. Only a hack of ignoring, not recording, >>> or commenting out the filemon lines ending in >>> /tmp/legacy/usr/sbin/rm would seem to avoid the @rm >>> handling issue. Such might well have its own risks. >=20 > No hacking needed, there are a range of knobs to help. >=20 >> Just for reference for more about the sequencing involved: >>=20 >> Looks like in my example various . . ./tmp/legacy/. . ./*bin/ >> actually are links to files in: >>=20 >> = /usr/obj/amd64_clang/amd64.amd64/usr/fbsd/mm-src/amd64.amd64/tmp/legacy/bi= n/ >>=20 >> and the later after-install buildworld "Rebuilding the >> temporary build tree" step leads to the updated dates for >> files in that area, updated via the code that reports: >>=20 >> Linking host tools into = /usr/obj/amd64_clang/amd64.amd64/usr/fbsd/mm-src/amd64.amd64/tmp/legacy/bi= n >>=20 >> So the prior installworld leaves updated dates and the >> linking to those installed files makes >> . . ./tmp/legacy/. . ./*bin/* have the newer dates show >> up for the legacy paths as well. >>=20 >> In turn the dependency tracking via META_MODE uses the new >> dates on . . ./tmp/legacy/. . ./*bin/* files to cause >> rebuilds of more materials than if installworld had not >> been done. >>=20 >> It is not obvious if Bryan D. would find the effort to avoid >> this worthwhile for the contexts that drive FreeBSD's build >> environment choices. >=20 > For people that use installworld and also want META_MODE > it would seem some additional IGNORE work may be beneficial. Since some of the paths reported ended up being links (symbolic, as I remember), what are the principles for which form of paths should be the basis for paths in the likes of: .MAKE.META_IGNORE_PATHS .MAKE.META.IGNORE_PATTERNS .MAKE.META.IGNORE_FILTER Target of link? Path to the link itself, not the target? Both? (Something had interrupted my explorations back then and I'd forgotten about your note and have never done the exploration. Trying to partially answer a question on the lists lead to me reviewing the old thread and running into your note again.) =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Wed Feb 22 23:19:41 2023 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 4PMXDv3JYSz3sbBl for ; Wed, 22 Feb 2023 23:19:59 +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 4PMXDt1LqGz3pms for ; Wed, 22 Feb 2023 23:19:58 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=CWhSCYQu; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.66.147 as permitted sender) smtp.mailfrom=marklmi@yahoo.com; dmarc=pass (policy=reject) header.from=yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1677107996; bh=ZzGJvQjNGNcXZDCz3YmJgBhV0FyuXBjFUR+U3HWogPo=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=CWhSCYQu4NfvUCSah/0Ae7NJ0z2BV292UBhwBrNoo640Z49/IUoFwdMmnR2EK1lv8J74hMTxzjqbuNvR38X07Gi+PXnJhyqgYkP8GfzN97fHRD6xOYzF/lEy7ixiq8E0QhKo7lnTRh2mQYSvhAtrvD9ekUBltcoNhVrFiinrS5ijDe7QT61hdWPydqRHkJyy/Yh19jwyLUjWChQfqteyI1KJOj2qrb4OycONRCEGKbwMv7wv4dbl9+AVGI/1OoVEcg3K1trVVqaNl289K19js3Ve4sTE5Hhue15WhVvtR3LR6ziWQDNCaY3pSoKjHDshsByvOVWolZyENr1r3+55EQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1677107996; bh=i1mrxuTa6GN0r1o2rUjx9KZBWySJtQfKyeemBLnjHI5=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=l9+ANSy2AJ2ott+5ek3+C4vgdG0Z6Qr1E9+RfD1lQrfaAEecbwTTRvDtQO8JTH6WfDlqkqBK6+LMY5H6HJlXT2adcE94cT99HsNT2vMChXXTVaXhas33HeywV6XTrFVNr6B9jMZnvwccj3HCIrm7k+vvvIXeS/Z8077A0aGTCduc5n1LqNZNO2ux8EE2YzqTXB0ZxXUjuhYBXuenHSKXCXh46RkfUbgU/fbjQ2N83/VZOonz1uDRQWJ6A6YEEEJS7c+FDEZ/ENiK+yXvZrobneLpc+6BGAMxXzP/FzFroh2Pxxne3Bxel0L3Ty0a9F/0gfLyzlAloAMIanOjDjFnLA== X-YMail-OSG: VtEsv2oVM1nay4jEJ71qpDeTaPN_AplIYL2.ZeCj32TmNNFlHvhK.h2bK8E7qAa VgA6mzFktlILwBJ8GLrjyUIujmc3MTTkBQ7h83AUhqrviFJKutHv8ecPbUVqrgrYrXuK3z9MFkuK 84gfXZ75.O1wNvga8DQrgFZ_UxIbR6g2CUz2w9QCEpHWCnCdat4kqhaNiwEcqoq5QXhaqXgK1iLH T23F.brZmWbOjbeihj_TlPuazk.6zNLeScopXTGF1Ua2Z6MdcolrmPdk2sJeoULQJz67pSYI5Kmo dDgGWACa_71vlb2BEAN59tlsKZFQxzToqO1GcfNW6cf8S9x.898cPBH6uT7zEQJ8Hx4OyaVEcN3i oz2FQzGXwLJBBiXhBIboym9VWHRmSNoEXlLcaW5nXKI74VGmAoa4cD0l84x5u9jqYDVwWqS2Bxid yyNzzkiw2RyuTc4EcuWS0RzvFShSufGRqQiXKPebxsaSuvtjKYM8TSp9d1EeCQNeMY1qmAImdl3I QsrFAu.7t37HqgAim.xBgAAoIJ_3m353I08FXlp0txeIrz20UYP3ZNOXmRtJXth46NV6xXJf_uN3 BKRIIdEm_o2HIvpbDbk2Lz0ZHp6mRD6JW9KXBzMglYJOfYJEgjC6iQ4EuV1q0jexDJiI0NvTbOL1 Li9fMIpQsgFey5i_iT.eG3H1BGrWGAwN7yQo_aNlNE4zbVjPLq5nZoyRIXUVSiDK22DALIYO_tBu 4IHtjIkBhDR1LudIZbL5q3dd9tQQJEBmd_yvDwnj6dYZWljuvO5NBMbYrOFD_jWXe8CnIa5SWk5E 2bwMjI0UAAHRJ3JoJnmvia0hP9UMfCXDr984UujZBmWuRFlJyXNC6Lc5nLlpxJTPuHyzC4we5jZF XMrWwW8PIngTu6IHnV7yenp2CUTuHL_kVml3ci6ic7xbRqyB_VxQdce1Q2oJleaYf0iNtlkerNMU MMtQU64BEOPCp3KlVCiDkvuHERLJ8eGcedyHHdZw4yRj4Sl1ZWzDzgJt74Mq6ZJNDQODoaiHq9Xj pyDU9CLWTawbEtOdkPvA76dqa.vPYxtTr_boEKpKXoViN5xMV38YxpzyYQp93QGbW31KMPB70Uz. qrHVWy9LAMG9Rr_a8KQafs2EMfZry8P0HDKnborhA5SarGeyYNwAUOWZh98AKcnUQaj7GRfiHNa5 lpplxw6MPC_H6O7q8Tfc608CU27aQ8eNNiR0IB7BYq4FCQKLB_FOa7VHBNky9flc9cuNCfZCQ_Df V835d0nX.xwgG7kthDjg6sXZngPrxX2OuX.5qa7iOekuoHFMBJ4KX_Y45u0Yk84sRIUd18nD.rmF 8ADfmh.D.wKIgKY5Le3xKRYg1ljXOAFUPh.05yK2iFx0tAM22tb3s5x6itVwB5MPAfuOi_wm_gf8 lKu66aiPzxcSK3R_M.c5COtOZvYdXtTgvC_v3e3CXUkIunxFnNOAjZ2M5CVNlc5K6FvjGIlcFkiE YlvhhUq8xKZBlm.O83Z420zWivAtuEZlwRcIab_tHMFUBLrUFGbz4YPet7nOJfmr4QX0XM3FODjr mpm3FmxJEw6xo4zmbU3NFExBUWpRLnvXE1FuQpDj1ZsLbWGpmV3J1q4nptF4VEjXKHsRXURxWOJV 0gOKUQfWbTrwO6W7MVcfBuqsgf3aMif2BbpUxyxx1o7IGyErVZkAydnZVtiLUBFVqHMTADIIMr0v fwynEedmAIjmG8L4G2Nr3mo.sT.FIy_s_86QsjWQZXTj4JNltiGC_Z_u8QZxIHQyuFkp_nXgMNQQ J8y0nClLExyXlFBMOKzghwmVEem4j8XZcvJdUgfhqDEX2bh_CF2CUXcW7TBNKMQpp6AKoTo2L94E 9epA5nU4CbOogOq4.M0CS1rbm79SGwf1kXoipRAmRtHug.gV0El4UcuSNWoYSWabPg9O9cQtL7a5 XSw0PMNVZ3sYxY3pLciez9e4rB33b869M6w15Wmvn4aTTUFam_.jeKzFRgIgQdhqgfHjFl5R.euc NzLmZOimhl7tKPKk7zoyPUnqg64ZF93M7WFmYIAggK_hd0ZQDQ7wxLxvpJrLD7HNK0jIibm3OB__ RK4VYqBQ5F8s4Zs4xekIub54GbveHLST1yMe0FJv5JsBlLM9SAnd3fo_1QlxMMwgtW0asiPGTaYE teXP7qrg9G1OuvcfRPtInXkjvbP9BVS2hidT8udPqJ0ydW6UyugA_w2lwsyMtR6vTMwMV52Nohaj GZ3s9gPVQayFKKKIBRjrDJqjQhPPTq4yre3SMIJr.SUk9vT0R96_fn_p4z0vWOWP5gmNs9I6mqQ- - X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic317.consmr.mail.gq1.yahoo.com with HTTP; Wed, 22 Feb 2023 23:19:56 +0000 Received: by hermes--production-gq1-655ddccc9-zvr4c (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 562c41f8babe2cce96acd2a118ed444a; Wed, 22 Feb 2023 23:19:52 +0000 (UTC) Content-Type: text/plain; charset=us-ascii 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 Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.400.51.1.1\)) Subject: Re: FYI: Why META_MODE rebuilds so much for building again after installworld (no source changes) From: Mark Millard In-Reply-To: Date: Wed, 22 Feb 2023 15:19:41 -0800 Cc: Bryan Drewery , Current FreeBSD , Peter Content-Transfer-Encoding: quoted-printable Message-Id: References: <3345EBA5-A09C-4E3F-B94D-39F57F56BDBB@yahoo.com> <73088.1611797582@kaos.jnpr.net> To: "Simon J. Gerraty" X-Mailer: Apple Mail (2.3731.400.51.1.1) X-Spamd-Result: default: False [-3.48 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.98)[-0.981]; MV_CASE(0.50)[]; 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]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; ARC_NA(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.66.147:from]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; RCVD_TLS_LAST(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@FreeBSD.org]; TO_DN_ALL(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; FREEMAIL_FROM(0.00)[yahoo.com]; MID_RHS_MATCH_FROM(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; MIME_TRACE(0.00)[0:+]; FROM_EQ_ENVFROM(0.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.66.147:from] X-Rspamd-Queue-Id: 4PMXDt1LqGz3pms X-Spamd-Bar: --- X-ThisMailContainsUnwantedMimeParts: N [Added a question about a possible typo in the old original message.] On Feb 21, 2023, at 13:31, Mark Millard wrote: > [This will be a question relative to the old material below.] >=20 > On Jan 27, 2021, at 17:33, Simon J. Gerraty wrote: >=20 >> Mark Millard via freebsd-current wrote: >>>>> Given an already built, installed and booted system version, I've >>>>> noted a big difference for META_MODE in 2 rebuild contexts (no >>>>> source updates involved): >>>>>=20 >>>>> *) Prior buildworld buildkernel, installkernel, installworld, boot >>>>> presumed before (A) and before (B) below. >>=20 >> Yes installworld is going to cause problems unless you tell meta mode = to >> ignore everything outside of the src/obj tree. >> But even that isn't enough as you note below. >>=20 >>>>> So I used make -dM for the commented buildworld buildkernel lines, = logging >>>>> the build output and later diff'ing them. >>>>>=20 >>>>> Result that I noticed? Lots of lines uniquely from (B)'s case, = ending with >>>>> one of: >>>>>=20 >>>>> file = '/usr/obj/amd64_clang/amd64.amd64/usr/fbsd/mm-src/amd64.amd64/tmp/legacy/u= sr/sbin/awk' is newer than the target... >>=20 >> Yes. That would be expected. >> I think Bryan added some knobs to mitigate some of this. >>=20 >> grep -n META.*IGNORE share/mk/*mk >>=20 >> might be instructive. >>=20 >>>>> Many/most/all(?) of these seem to me to be unlikely to actually = need to >>>>> contribute to what needs to be rebuilt (just based on being = newer). So >>>>> the option to ignore (some of?) them could be useful in making = META_MODE >>>>> builds quicker. >>=20 >> Yes on all counts. That's why bmake provides a number of knobs to >> ignore such things. >> They are listed in the man page in increasing order of expense. >>=20 >> One of the risks of the sort of introspection meta mode does, is = delving >> too deep (like the dwarfs ;-) >>=20 >> The .MAKE.META.IGNORE_* and .MAKE.META.BAILIWICK variables help to >> contain the potential insanity. >>=20 >>>> The following from one of the .meta files makes the point that rm = use >>>> in the example is unlikely to be important to needing to rebuild, >>>> despite it actually causing a file rebuild. Nor is the specific = echo >>>> command listed relevant. Only the "ar" command is: >>>>=20 >>>> # Meta data file = /usr/obj/amd64_clang/amd64.amd64/usr/fbsd/mm-src/amd64.amd64/lib/libc++/li= bc++.a.meta >>>> CMD @echo building static c++ library >>>> CMD @rm -f libc++.a >>>> CMD ar -crsD libc++.a algorithm.o any.o atomic.o barrier.o bind.o >>=20 >>>> -- filemon acquired metadata -- >>>> # filemon version 5 >>>> # Target pid 22471 >>>> # Start 1611359217.214996 >>>> V 5 >>>> E 22961 /bin/sh >>>> R 22961 /etc/libmap.conf >>>> R 22961 /var/run/ld-elf.so.hints >>>> R 22961 /lib/libedit.so.7 >>>> R 22961 /lib/libc.so.7 >>>> R 22961 /lib/libncursesw.so.9 >>>> R 22961 /usr/share/locale/C.UTF-8/LC_CTYPE >>>> F 22961 22962 >>>> E 22962 = /usr/obj/amd64_clang/amd64.amd64/usr/fbsd/mm-src/amd64.amd64/tmp/legacy/us= r/sbin/rm >>=20 >>>> The timestamp on . . ./tmp/legacy/usr/sbin/rm is not >>>> actually relevant to if libc++.a needs to be rebuilt. >>=20 >> True.=20 >> If there is nothing under .../tmp/legacy that should be counted you = can >> just: >>=20 >> .MAKE.META_IGNORE_PATHS +=3D that path Was that supposed to be ("." vs. "_"): .MAKE.META.IGNORE_PATHS +=3D that path The later ones listed have ".". >> which would be the cheapest option. >>=20 >> If however there are things that should be considered you'd have to >> use a much more specific list of .MAKE.META_IGNORE_PATHS or (Same question applies to the above.) >> perhaps something like: >>=20 >> .MAKE.META.IGNORE_PATTERNS +=3D */rm >>=20 >> would ignore an rm binary regardless of where found. >>=20 >> worst case you might need something like: >>=20 >> # realpath >> .MAKE.META.IGNORE_FILTER +=3D tA >> # ignore anything here >> .MAKE.META.IGNORE_FILTER +=3D N*/tmp/legacy/usr/bin/* >>=20 >> Unlike .MAKE.META.IGNORE_PATTERNS which is a list of patterns to = match >> the goal with .MAKE.META.IGNORE_FILTER is to reduced to an empty = string >> paths to be ignored. >>=20 >>>> Of course, the structure also point out the judgment >>>> is specific to understanding the sequence of CMD's >>>> listed above. Only a hack of ignoring, not recording, >>>> or commenting out the filemon lines ending in >>>> /tmp/legacy/usr/sbin/rm would seem to avoid the @rm >>>> handling issue. Such might well have its own risks. >>=20 >> No hacking needed, there are a range of knobs to help. >>=20 >>> Just for reference for more about the sequencing involved: >>>=20 >>> Looks like in my example various . . ./tmp/legacy/. . ./*bin/ >>> actually are links to files in: >>>=20 >>> = /usr/obj/amd64_clang/amd64.amd64/usr/fbsd/mm-src/amd64.amd64/tmp/legacy/bi= n/ >>>=20 >>> and the later after-install buildworld "Rebuilding the >>> temporary build tree" step leads to the updated dates for >>> files in that area, updated via the code that reports: >>>=20 >>> Linking host tools into = /usr/obj/amd64_clang/amd64.amd64/usr/fbsd/mm-src/amd64.amd64/tmp/legacy/bi= n >>>=20 >>> So the prior installworld leaves updated dates and the >>> linking to those installed files makes >>> . . ./tmp/legacy/. . ./*bin/* have the newer dates show >>> up for the legacy paths as well. >>>=20 >>> In turn the dependency tracking via META_MODE uses the new >>> dates on . . ./tmp/legacy/. . ./*bin/* files to cause >>> rebuilds of more materials than if installworld had not >>> been done. >>>=20 >>> It is not obvious if Bryan D. would find the effort to avoid >>> this worthwhile for the contexts that drive FreeBSD's build >>> environment choices. >>=20 >> For people that use installworld and also want META_MODE >> it would seem some additional IGNORE work may be beneficial. >=20 > Since some of the paths reported ended up being links > (symbolic, as I remember), what are the principles for > which form of paths should be the basis for paths in > the likes of: >=20 > .MAKE.META_IGNORE_PATHS (The above may be a typo relative to .MAKE.META.IGNORE_PATHS .) > .MAKE.META.IGNORE_PATTERNS > .MAKE.META.IGNORE_FILTER >=20 > Target of link? Path to the link itself, not the > target? Both? >=20 > (Something had interrupted my explorations back then and > I'd forgotten about your note and have never done the > exploration. Trying to partially answer a question on the > lists lead to me reviewing the old thread and running into > your note again.) >=20 =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Wed Feb 22 23:26:29 2023 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 4PMXQ75C3mz3sbgC for ; Wed, 22 Feb 2023 23:27:59 +0000 (UTC) (envelope-from sjg@juniper.net) Received: from mx0a-00273201.pphosted.com (mx0a-00273201.pphosted.com [208.84.65.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.pphosted.com", Issuer "Thawte RSA CA 2018" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4PMXQ71wpqz3sBW; Wed, 22 Feb 2023 23:27:59 +0000 (UTC) (envelope-from sjg@juniper.net) Authentication-Results: mx1.freebsd.org; none Received: from pps.filterd (m0108158.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 31MKX6t2010215; Wed, 22 Feb 2023 15:27:35 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=to : cc : subject : in-reply-to : references : from : mime-version : content-type : content-id : date : message-id; s=PPS1017; bh=g3+ugA/3sPYzd6rwWnFJ8+kfpyLqr8JgYlleJw8fOMQ=; b=WYEbbYDvOzpjt4u9WoDWCnqkH9l9lR6z/9330pgezXOslxUxWQIGivRcm/4DQK3H3B+w 43bm16nin0HfQFWe/esNyq8lS0/2Fcpb4h9L7Yd1pOYt2gxjYMOooVfGbD3llt6FWU8s uaFHIX+Fv0jyvK0gj3fURyRRUeThW1E2crz4kkOSYb1n8451c/mn60wV9vaUxHG0Apqa 6D0q0rinjOLsCBtvOMeObMtIuRYY5bu9u0iB/t3mzEucXn3yuUU7ce6IynrwV+gPBWa6 bqcZs/rm2VJshQ5DyIdnWzgYK4MKvTKjL5k3kDY4qjaAkrMmkxWOwErjUZ7l6bhwn9AP PQ== Received: from mw2pr02cu001-vft-obe.outbound.protection.outlook.com (mail-westus2azlp17012023.outbound.protection.outlook.com [40.93.10.23]) by mx0a-00273201.pphosted.com (PPS) with ESMTPS id 3nwn3m0xy0-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 22 Feb 2023 15:27:35 -0800 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=OWBZybk6hxIck1ck1XRXIX+0j3I16CSC/a6DX75yNa7NM97Y2K5BdJZpEEKZYcW1OO8XxmwSNRb4FWhPaAE3eT9d+gI3QmHT82IbEHnTX4ry5IqwK/52sLcLWNw7gfHSvI47ltkw3A4Q6nH5cXNjocTXU92vB5kbRV/0QUwzeoTQKFcYLlmcRxCw5qzRCJq2fcTO9ISFowQewDRJBUsApWi3QHa6TJ5B2r/MPP7mDkGUKu2tYdsVBnxc4Uze9j8qjc6UzVwrMi854nbFACqUdg75/jtj+/8F6StVBqnDDmMC6qDIMEfrTWN6N2eMY//BbvG7byoU592joWx1fpr4ZQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=g3+ugA/3sPYzd6rwWnFJ8+kfpyLqr8JgYlleJw8fOMQ=; b=h0W1fkW6OUAdBAefYq/tMzce2lR+9vS4eiiPoS+vw8AndR+YmR4Y/aovRDVleDtRGgjO0dgJMDT2E7fNGe+hsw+USQmKLkBmMJIidF7RTBRGLmqcfg5amH8LUvPd1iJqyn9pTpGjibfMuLFGoFJ3bwU5tZ6hWC5mwhLuELWbDu0fLLLLd+MUClSNpz8y7wYZQf4SFotY1MLDEdckWJB+mMMgfUjH0eU1jK9djEjz0YILxFJpgJFwz6Mii3bvx9Gh3ULFBarxaoQ5kIyARGAzIL5pMbxc7AAkIzCze6Lz3buZccdBrqGAMkdpzjXtfRMUGqgxF2tSZktKGrBKNVqLgg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=temperror (sender ip is 66.129.239.15) smtp.rcpttodomain=yahoo.com smtp.mailfrom=juniper.net; dmarc=temperror action=none header.from=juniper.net; dkim=none (message not signed); arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=g3+ugA/3sPYzd6rwWnFJ8+kfpyLqr8JgYlleJw8fOMQ=; b=jcIkoENBUymxcGlzVTXPEas2lF0q9xYygwzTsdRGfozNRpCAZPIwEhEsYZ2kqQIkkeiENeCEWl6dNYuDeCnA27hlr12QPLuwlKyqNWZDDNIhp9Sb8LNzOt8yubJWFsb8LTR3qtjPzJVPI/Bi6bASdNURMgjaOcs/lrNQEPf5Zjg= Received: from MW4P222CA0020.NAMP222.PROD.OUTLOOK.COM (2603:10b6:303:114::25) by PH7PR05MB9858.namprd05.prod.outlook.com (2603:10b6:510:2b2::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6111.19; Wed, 22 Feb 2023 23:27:29 +0000 Received: from MW2NAM12FT074.eop-nam12.prod.protection.outlook.com (2603:10b6:303:114:cafe::6) by MW4P222CA0020.outlook.office365.com (2603:10b6:303:114::25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6111.21 via Frontend Transport; Wed, 22 Feb 2023 23:27:29 +0000 X-MS-Exchange-Authentication-Results: spf=temperror (sender IP is 66.129.239.15) smtp.mailfrom=juniper.net; dkim=none (message not signed) header.d=none;dmarc=temperror action=none header.from=juniper.net; Received-SPF: TempError (protection.outlook.com: error in processing during lookup of juniper.net: DNS Timeout) Received: from p-exchfe-eqx-02.jnpr.net (66.129.239.15) by MW2NAM12FT074.mail.protection.outlook.com (10.13.180.212) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6134.18 via Frontend Transport; Wed, 22 Feb 2023 23:27:28 +0000 Received: from p-exchbe-eqx-02.jnpr.net (10.104.9.15) by p-exchfe-eqx-02.jnpr.net (10.104.9.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.30; Wed, 22 Feb 2023 17:27:27 -0600 Received: from p-mailhub01.juniper.net (10.104.20.6) by p-exchbe-eqx-02.jnpr.net (10.104.9.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.30 via Frontend Transport; Wed, 22 Feb 2023 17:27:27 -0600 Received: from kaos.jnpr.net (kaos.jnpr.net [172.23.255.201]) by p-mailhub01.juniper.net (8.14.4/8.11.3) with ESMTP id 31MNRRwA024704; Wed, 22 Feb 2023 15:27:27 -0800 (envelope-from sjg@juniper.net) Received: by kaos.jnpr.net (Postfix, from userid 1377) id 8F429208F0; Wed, 22 Feb 2023 15:26:29 -0800 (PST) Received: from kaos.jnpr.net (localhost [127.0.0.1]) by kaos.jnpr.net (Postfix) with ESMTP id 8E9E120C0F; Wed, 22 Feb 2023 15:26:29 -0800 (PST) To: Mark Millard CC: Bryan Drewery , Current FreeBSD , Peter , Subject: Re: FYI: Why META_MODE rebuilds so much for building again after installworld (no source changes) In-Reply-To: References: <3345EBA5-A09C-4E3F-B94D-39F57F56BDBB@yahoo.com> <73088.1611797582@kaos.jnpr.net> Comments: In-reply-to: Mark Millard message dated "Wed, 22 Feb 2023 15:19:41 -0800." From: "Simon J. Gerraty" X-Mailer: MH-E 8.6+git; nmh 1.7.1; GNU Emacs 28.1 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 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <7866.1677108389.1@kaos.jnpr.net> Date: Wed, 22 Feb 2023 15:26:29 -0800 Message-ID: <10819.1677108389@kaos.jnpr.net> X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: MW2NAM12FT074:EE_|PH7PR05MB9858:EE_ X-MS-Office365-Filtering-Correlation-Id: 04014bd8-2d4a-474d-0e8f-08db152c5cd2 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: mHV9IpqETvDdFjzUe0UHCDJaxwt1H3Ecq629CSrQH7IRRDjC5QTu8l68+hcnV2HqXALProCIXHbDUwzQ/KLlA7jjijXmI5ov3SLIqiJtYpiGjY3RHBqsg1PzFy3RajWenAkHXtbzl+qSBVpt/jKSYv1WGpqgoXr+9aXsLXZtuSP2vZip5Fj8m5t2g+TQXHkcXOlwB3TMZYDas7t/C/WHBVfDE0s5F3WD3bqhOq5pMt7ODWQFsSzogL1cm1PF/bcEdxDJ87ksRSUOqoKnsPJMpDvMWtuGgcHbEBG/ZAzg9HmmMbDaaqI+o953Fi+OZ+qxWUe4dwTsM2SRkdO7O3t2pFKQUVGZC0mLyyHbppyGFBh/9wfdAUunwhdl96OcryC7HqLg2mKzO0aaNUFg6tWnSnDW7ZJtUzhOMYUFna0PvdsBtkuU7HhlgRo/lCRMCXeZqrSqcv+poCp6P1ylo3IQNIGYZImwRWgTeG9fd88FD5qxBx0he8/byRcaHDG6qorj7XPLfj1MWULsRZRRwCN24CkEJLHfcRSiJ03dCtuV9RdX5S3ogLVVRh8UEmBsPgwKVOqqc8HEMThYCurRVVeoksDCDNfQNO1HbgjLMDCsqPyvfuP7bvYQN09oh37/5G3liAHJUcRjaKxIfq0S54rzgUGRKdJ/Gsv0wqrKtkfV3JUmCP3x4mSd2p2PHLAfltKfr6GPYNLh9N7Fl6173FgfX9uPTZyF8adkQ02zLXcuqD4= X-Forefront-Antispam-Report: CIP:66.129.239.15;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:p-exchfe-eqx-02.jnpr.net;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230025)(4636009)(136003)(396003)(39860400002)(376002)(346002)(451199018)(46966006)(36840700001)(40470700004)(54906003)(7126003)(186003)(9686003)(40480700001)(63370400001)(4326008)(55016003)(8676002)(70586007)(5660300002)(6916009)(63350400001)(70206006)(107886003)(26005)(8936002)(6266002)(7696005)(336012)(40460700003)(478600001)(47076005)(356005)(41300700001)(316002)(82310400005)(82740400003)(86362001)(81166007)(2906002)(36860700001)(4744005)(36900700001);DIR:OUT;SFP:1102; X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 Feb 2023 23:27:28.2602 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 04014bd8-2d4a-474d-0e8f-08db152c5cd2 X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4;Ip=[66.129.239.15];Helo=[p-exchfe-eqx-02.jnpr.net] X-MS-Exchange-CrossTenant-AuthSource: MW2NAM12FT074.eop-nam12.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH7PR05MB9858 X-Proofpoint-GUID: G03-8XA7QtwbFb7zFZLi9gCvNP3R4UC1 X-Proofpoint-ORIG-GUID: G03-8XA7QtwbFb7zFZLi9gCvNP3R4UC1 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.219,Aquarius:18.0.930,Hydra:6.0.562,FMLib:17.11.170.22 definitions=2023-02-22_10,2023-02-22_02,2023-02-09_01 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 malwarescore=0 priorityscore=1501 mlxscore=0 bulkscore=0 spamscore=0 suspectscore=0 clxscore=1011 adultscore=0 phishscore=0 lowpriorityscore=0 impostorscore=0 mlxlogscore=797 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2212070000 definitions=main-2302220203 X-Rspamd-Queue-Id: 4PMXQ71wpqz3sBW X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:26211, ipnet:208.84.65.0/24, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N > >>>> The timestamp on . . ./tmp/legacy/usr/sbin/rm is not > >>>> actually relevant to if libc++.a needs to be rebuilt. > >> > >> True. > >> If there is nothing under .../tmp/legacy that should be counted you can > >> just: > >> > >> .MAKE.META_IGNORE_PATHS += that path > > Was that supposed to be ("." vs. "_"): > > .MAKE.META.IGNORE_PATHS += that path Yes, sorry. strings `which bmake` | grep META.IGNORE .MAKE.META.IGNORE_PATHS .MAKE.META.IGNORE_PATTERNS ${.MAKE.META.IGNORE_PATHS:O:u:tA} .MAKE.META.IGNORE_FILTER ${.MAKE.META.IGNORE_PATTERNS:@m@${.p.:M$m}@} From nobody Thu Feb 23 00:40:26 2023 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 4PMZ255fS8z3sgX6 for ; Thu, 23 Feb 2023 00:40:45 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic308-8.consmr.mail.gq1.yahoo.com (sonic308-8.consmr.mail.gq1.yahoo.com [98.137.68.32]) (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 4PMZ253KTzz41Wc for ; Thu, 23 Feb 2023 00:40:45 +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=1677112843; bh=CtfVxs3doeDuWibjx1myWuDF0wE/HU+PXJyUw+gncv8=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=YhUYxuzZD32FhJBOaE3ahg6n6HM9oLSKNZIogwmOZTE9HxMuyUpBBEVMqyiWRMkcO7MdcoWAHLuHCVESaLOPugBwRGQTnyDV7/ziLMxXbtDnEvVog4p6Thwwtmhm4HdDdk2K7qBCliyCHruU4PMxgSjH2ABtAJfYMSTAfys3I+KiBDrYFy8B27T4Jw6TopxGvLRB7+Q94TU2ffL/khzewiFMt8OAC4OY8grE/9zmiGAuNo9sOFJCn4lYgTza0t6jhFpmV8daoq7UX6i5nhY0klu7G58Nv8OQpnb598igX+sLg417jcJLQK6OGof2+a0vrFMM/BXwJAyZTXFbhHjXOQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1677112843; bh=MwpYu3+jXMZ8FfGYajqAh5jPRGqDZL3UbJzDSG++PlH=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=TfeKBZBGRPVxz4+QkQOj7P8GU05Um3drA/80D6HFTlwyEo9Qqrsh1wGg6zj1yb654aXInSkJ/3DoZQ4BMPxfLuQXjgqYEnJyafJh4dUADgArM6mxpG4qZ7zJsF6CbECfMQyJOD/OOqZCVg9ox1Rm3oFwY8Y0nF7zMK4o4VU0+wNY/whVzf9dIOQa3NdzXNf+BBb/ihuaSk58TWio5NdW/9A6bE9vXG0RTqc9esBt8Ii2zuwuQHcrnLc/+Uvih/l0mMEkLs/QvX2tjgLDv4gwzEtp1eB+y5UkOaPxJikHhBMSWwczQIQ6awd7F4bAUifktDevU3NJcyZK/Bd8kzivGQ== X-YMail-OSG: 9MKH4MkVM1kj_yRSlLSpamIRcrYFBsZ8wfw_EwbOe_UjxqqeFyBiVk1DDeLej_h nzJJZaKLIvF_fKDve0TgzoX8taznjeUTMsKssPv0BO_gSVx7FK4fFJkG0qtaUAHRHAqv0b_NSS1z f1qxcE5eKRUmuGK07Qm8XhUmDeyoQ5EJEBgpJOQKSk0xWKx0AyhtENls6WyYtHY3OBF.MkJ9W378 oJRSqKF7nbRehIO__Bv0VMiYMO1OO2jA6Kqnj219NQdqY7lzwae5Siv.ESEgnEhKfZVF2embTLjM yjTbZLXstnaxt_ccqrf.wWQC.hJpq.10ivs6FM4tJizh.y7VRQOjZutXL2veE4t88OKc5ldot33e dCGeK59q4vQgw13E9G5q67izXB.USoy1coZusOOA6seMTvTCvALgpM7jrVqjjlNt7xNrdGX.7xzJ Bxkd_Trh3JcnpbJZlhrkdtEh7W7jkHxgnW8BOQUGmoC351PQBqx9_ezbjfEgx_3LmLnCtrmu.jqQ a8wMN2zuLgVIolYgVlckvYeYd3my0DRbelm96b_A2YM.VuPrFILY6yUJIK5H87oK5vF.PwoOQ9e1 RJvJ7AnSvnaA8qiAhRTF7w.xyEHSdJ49dJTq9Q8D1ZGDsV69QtvQR7wg8bHVmg0uZMUYICqxpdb0 cJ1ajdB.68mlV0F9xKGhYG8vsCkzTUNKI26l9MKy24y2Y3SRcbvejPaEsFhVvw4CC1wgGuio_8Fl muxZQMbdIM0CYFzupFEhoPz2IjgEvjLMepcvA3AhRqqK2zZcV.Njera_ArgRNLvnpaM7I3iu9cko 2CNtsO4oVunAs91HE5rMhxTdlyg5gaglbAuqKONnAKKM7MmOAXABLGgCpBGOcjVDyyiIqhQPbqJw 7NSNiYbOYQHJezZ7GO2WrvmV7dqpD.rn__NvZzgcUejsAtbXwfw4GieX.cNF3xEntfzuICaalbNG n1mSLmBGtrh0mmN5amJPA4ahw3Dk7WoWwkGnwIwPD2_YrtAurhrrrl2SGIEGQB_x1FtPjmAAMsR. Dmnj8cG_ftn4npdE2s6EfMAkRCWK7rQRNgFLdAd_qnkICU3J2H6ypo9RfKqcCapf75mEO.ckf.Q0 w2AZdfjHIkE48FHNkqU_BV2JZdg_KCzcolxM4SqnvAyspHwMKVBdkeH4tDQdXByav9HZKq.PgVcp G7EBWJh17nCUk9iZZl2klNPBt4pw3G8ewT2CFmgooWhl1WxBT6540DiLlspfqwj1Xjy.Ho16l7_s hpZETE_CA1WA7kfazLWJIzTNNtDEC_6SkeHEzY0MbmRsQUyOh5ypoyl8xCYD_froDOdvEr1qh_Ce PYMyWJg5NjSVf_TIjdeXyg591Ej7R.ICZ5vEMegH6jL83GnbfeR7DYXFKdj.s6op6607hj2fOQf1 7tVdSAv_xfYHEj2oRTHzNuRIMpHtpbqExXY25sfu2Td1M7QXmNYN3nj6zBDqbhueDo3GnvAiBBGe 0Si1kOqCWRgRu6IF84YDAHQQT5g28CpSid2eH30KuaWcRmeOQ3X2olw9ilAo.5JG6aL8zgT5CUGE y_IVPYo5xSYdiLspaIwD1HHf8tjj.BxFCLNHhmm3IiAZOLpZj.uxe1TpFoAgKltLjP8wsDdtql8n e7cuhb5HlECppMmRGO_JWsp8EM4UpmTANVmp2Dr.PEqNi2EYyCHk4fCRNJrE83KnYH9ahmRBUmJc 0m94QVDHhEEd1Nl09JS5fLo9NgnnZ3NYsVmzcYhgXqFmrA4ldmiu7KLyPcsfai51Z93mXrplvLqW ckOcEsWBzUSF2H0rYR48bGMmfc0DJYDHbPFvw2lzkCZzNpticjRo8drQ9ctEX0cvPeRv_Xbb62b3 NqiI1AjITolMsVso64P54QbH6pjnh1XKDf0zeayCTGn02tjJO4cfTLwLEry0K0lg.37dCVX4NTYH kaOq61bTW65FPSo32it6XXnaWMEG7slAHpDCfkbY.qWvOj38DQp79npe3kfv9PNVKw.n2TkggtWY kpVHk4_cJwwn1Atv5Gq69vnT7jdBWY6bthn4SQC8DIXC9JUNPkTXW2RpcxpA1IqwgFeY.SkCM_pq D5gJCtMkzLRYWnB.iOOU9yTVttfLK8JipcAI7faw3akkKrRez1Kd4WyMMwnhzyFzCZ4CV9o6HaEK xP.gvxV_YvmoNf5jWcq7TZaQ8_T_T6b5T_d019PqSAp2C1xGmqbKT3pv8MpBv0vpVaWsjH7QouVw DmOhpEt8MQtgFt7NADi1c_bw0pWPvC7E9UP_96ofDp._kgHL24C9xydZYMHKmxqtwDNZS_PoU6E7 s X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic308.consmr.mail.gq1.yahoo.com with HTTP; Thu, 23 Feb 2023 00:40:43 +0000 Received: by hermes--production-bf1-57c96c66f6-l6456 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 3f52af8d572e457d8372567563304e33; Thu, 23 Feb 2023 00:40:38 +0000 (UTC) Content-Type: text/plain; charset=us-ascii 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 Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.400.51.1.1\)) Subject: Re: FYI: Why META_MODE rebuilds so much for building again after installworld (no source changes) From: Mark Millard In-Reply-To: <10819.1677108389@kaos.jnpr.net> Date: Wed, 22 Feb 2023 16:40:26 -0800 Cc: Bryan Drewery , Current FreeBSD , Peter Content-Transfer-Encoding: quoted-printable Message-Id: <76FA98EF-6184-4D7E-A01F-0EE8117D0D10@yahoo.com> References: <3345EBA5-A09C-4E3F-B94D-39F57F56BDBB@yahoo.com> <73088.1611797582@kaos.jnpr.net> <10819.1677108389@kaos.jnpr.net> To: "Simon J. Gerraty" X-Mailer: Apple Mail (2.3731.400.51.1.1) X-Rspamd-Queue-Id: 4PMZ253KTzz41Wc X-Spamd-Bar: ---- 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-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N On Feb 22, 2023, at 15:26, Simon J. Gerraty wrote: >>>>>> The timestamp on . . ./tmp/legacy/usr/sbin/rm is not >>>>>> actually relevant to if libc++.a needs to be rebuilt. >>>>=20 >>>> True. >>>> If there is nothing under .../tmp/legacy that should be counted you = can >>>> just: >>>>=20 >>>> .MAKE.META_IGNORE_PATHS +=3D that path >>=20 >> Was that supposed to be ("." vs. "_"): >>=20 >> .MAKE.META.IGNORE_PATHS +=3D that path >=20 > Yes, sorry. Thanks for the information. > strings `which bmake` | grep META.IGNORE > .MAKE.META.IGNORE_PATHS > .MAKE.META.IGNORE_PATTERNS > ${.MAKE.META.IGNORE_PATHS:O:u:tA} The -dM output's "is newer than the target" lines show the path from before the above transformation. (The :tA results possibly could use another sort/uniq sequence for the realpath results?) I've been pondering things because, so far, my attempts to experiment with this has failed to make the -dM output lines for the paths go away and it still does the related build activity. I've been trying the likes of: .for ignore_legacy_tool in awk cap_mkdb cat cp crunchgen crunchide dd = egrep env file2c gencat grep gzip jot lex lb ln m4 mkcsmapper mktemp mv = patch realpath rm sed sh touch truncate uudecode uuencode xargs .MAKE.META.IGNORE_PATHS+=3D = ${OBJTOP}/tmp/legacy/usr/sbin/${ignore_legacy_tool} .endfor .for ignore_other_tool in ctfconvert objcopy nm .MAKE.META.IGNORE_PATHS+=3D ${OBJTOP}/tmp/usr/bin/${ignore_other_tool} .endfor in what I use for make.conf via: __MAKE_CONF=3D/usr/home/root/src.configs/make.conf It is using paths that match the -dM output lines ( sbin use despite sbin -> ../bin being a symbolic link). Note: WORLDTMP is not defined that early, thus the ${OBJTOP}/tmp use. -V.MAKE.META.IGNORE_PATHS is showing the paths I would expect, matching the -dM lines. So I'm still pondering what might be going on. > .MAKE.META.IGNORE_FILTER > ${.MAKE.META.IGNORE_PATTERNS:@m@${.p.:M$m}@} =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Thu Feb 23 00:49:09 2023 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 4PMZFW3Hysz3sh6k for ; Thu, 23 Feb 2023 00:50:39 +0000 (UTC) (envelope-from sjg@juniper.net) Received: from mx0b-00273201.pphosted.com (mx0b-00273201.pphosted.com [67.231.152.164]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.pphosted.com", Issuer "Thawte RSA CA 2018" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4PMZFV4KH2z42yX; Thu, 23 Feb 2023 00:50:38 +0000 (UTC) (envelope-from sjg@juniper.net) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=juniper.net header.s=PPS1017 header.b=E19H4g9o; dkim=pass header.d=juniper.net header.s=selector1 header.b=W2EgunN5; spf=pass (mx1.freebsd.org: domain of sjg@juniper.net designates 67.231.152.164 as permitted sender) smtp.mailfrom=sjg@juniper.net; dmarc=pass (policy=reject) header.from=juniper.net; arc=pass ("microsoft.com:s=arcselector9901:i=1") Received: from pps.filterd (m0108161.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 31MKJ2th031861; Wed, 22 Feb 2023 16:50:16 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=to : cc : subject : in-reply-to : references : from : mime-version : content-type : content-id : date : message-id; s=PPS1017; bh=jgKnwUNWh2t5vrpC6+oEEns75sq5ApNupd6leK37Abg=; b=E19H4g9oOlhLZ9BkxTE3pp6TU+sPCdxnytVuZ51NIXTQDnkl+OlN8LJQR+JrcNg1w9A1 igWE3xKFzS6G4soH2XUA+rCv/4Hjbbo77WZwhBX4gCK/WMj2HzjhaLNJNQDVKA4RTUtO m7CfleWMYxhTFf+pD/C//gMNlbvpYnaE4CIB1RSe0DkkuTrDPsKHWn3N8kYkBqY0vszb cYgPqrYHBPgjgW+b8lI7gzBSon5cbbSko+rb/T/lQ04BWzpsdkFziY/cJwHMjhUKcyZp ip32+JcCWoYJ2XQ4UsXqgOi90NUmK63DWgDDIsxOQ2amaCDz81yvrGkAm8XCV22ctFkD uQ== Received: from mw2pr02cu002-vft-obe.outbound.protection.outlook.com (mail-westus2azlp17013032.outbound.protection.outlook.com [40.93.10.32]) by mx0b-00273201.pphosted.com (PPS) with ESMTPS id 3nwmyqsf90-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 22 Feb 2023 16:50:16 -0800 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=BkeTmotMqvLJi2O5KmOHUAQ9hRp6DvfuZQY4uxM0X7qWa2QUrQQyWg482VbiiHrrq/sJH4MWGdAdet+U4bBgEBA9WYTJt9MyyCa1FIYmr3R9IaFlPL0ornZPeO6Ca4uiA8ZDuZ8ls6lGy0a2EtmrNnv2ctxadt87rDvo2qJmunC849BpMxb7X50s2edhL/ODgJzOGcEbXLsA0aunF/BjjHitm9TA5J7Sq1oPfWWwFp8PBwGCg6agPdCZ/jzhChWWe0nj/cyWthMXszvbbgot/qgwie0YscVz2kU3sdRv31XO9TS9ExS7Fq4R/9Yn+29MwtkEq/45EpaTLH4QMugtsw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=jgKnwUNWh2t5vrpC6+oEEns75sq5ApNupd6leK37Abg=; b=CGoxkSl31ztOkFsHyAN4jHFWZVCSoLXvTT3g/xO5olW5jTH+NVphmCItV9/WC1LettSRS52R5kkgpfcnSNx2gMqnyJNjM088K6lmPyxO4whIChW0Zn5PcKmsojoy5ss/w0LZwlT279iUu2BYKrZJNn1wGUL+aTlgibxkF9w2QqQ6/zt5EUlw0WXFULJo5YL3J0stBB2oPngzjqJYJJHVKbO3NwEMRwJBFluUabHXPyESVWR2QBWp7Pd2mBzkTcC1hLnDhSblTo5vBgiA7/MOazsTTjmXlvnHsjBuFr6IPyyEp7vTk3+k8rOydxAqlui1RiTUPb43QZeleo1QcVvVeg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=softfail (sender ip is 66.129.239.15) smtp.rcpttodomain=yahoo.com smtp.mailfrom=juniper.net; dmarc=fail (p=reject sp=reject pct=100) action=oreject header.from=juniper.net; dkim=none (message not signed); arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=jgKnwUNWh2t5vrpC6+oEEns75sq5ApNupd6leK37Abg=; b=W2EgunN5K9LB2wTRcr8+UIUeoEsFqOgJ88uBGJfz2vTcQc8HDJ7sNxDIo8omhsrqM/ECdFVfjyF5/Otpyx6o1w2Bqos+D5C3COFbBnV84/jkRWOYTf5Gx/7/mFqi4Fhwmi4GS8zVXQYtlxteYRDgSkVbksob8r3vdqcfMmqcRn4= Received: from MW4PR03CA0113.namprd03.prod.outlook.com (2603:10b6:303:b7::28) by SN6PR05MB4047.namprd05.prod.outlook.com (2603:10b6:805:21::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6111.21; Thu, 23 Feb 2023 00:50:12 +0000 Received: from MW2NAM12FT070.eop-nam12.prod.protection.outlook.com (2603:10b6:303:b7:cafe::61) by MW4PR03CA0113.outlook.office365.com (2603:10b6:303:b7::28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6111.21 via Frontend Transport; Thu, 23 Feb 2023 00:50:12 +0000 X-MS-Exchange-Authentication-Results: spf=softfail (sender IP is 66.129.239.15) smtp.mailfrom=juniper.net; dkim=none (message not signed) header.d=none;dmarc=fail action=oreject header.from=juniper.net; Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.15 as permitted sender) Received: from p-exchfe-eqx-02.jnpr.net (66.129.239.15) by MW2NAM12FT070.mail.protection.outlook.com (10.13.180.158) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6134.20 via Frontend Transport; Thu, 23 Feb 2023 00:50:12 +0000 Received: from p-exchbe-eqx-01.jnpr.net (10.104.9.14) by p-exchfe-eqx-02.jnpr.net (10.104.9.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.30; Wed, 22 Feb 2023 18:50:08 -0600 Received: from p-exchbe-eqx-01.jnpr.net (10.104.9.14) by p-exchbe-eqx-01.jnpr.net (10.104.9.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.30; Wed, 22 Feb 2023 18:50:08 -0600 Received: from p-mailhub01.juniper.net (10.104.20.6) by p-exchbe-eqx-01.jnpr.net (10.104.9.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.30 via Frontend Transport; Wed, 22 Feb 2023 18:50:08 -0600 Received: from kaos.jnpr.net (kaos.jnpr.net [172.23.255.201]) by p-mailhub01.juniper.net (8.14.4/8.11.3) with ESMTP id 31N0o8ck011092; Wed, 22 Feb 2023 16:50:08 -0800 (envelope-from sjg@juniper.net) Received: by kaos.jnpr.net (Postfix, from userid 1377) id 5584C20BAA; Wed, 22 Feb 2023 16:49:09 -0800 (PST) Received: from kaos.jnpr.net (localhost [127.0.0.1]) by kaos.jnpr.net (Postfix) with ESMTP id D2FF720BA9; Wed, 22 Feb 2023 16:49:09 -0800 (PST) To: Mark Millard CC: Bryan Drewery , Current FreeBSD , Peter , Subject: Re: FYI: Why META_MODE rebuilds so much for building again after installworld (no source changes) In-Reply-To: References: <3345EBA5-A09C-4E3F-B94D-39F57F56BDBB@yahoo.com> <73088.1611797582@kaos.jnpr.net> Comments: In-reply-to: Mark Millard message dated "Tue, 21 Feb 2023 13:31:37 -0800." From: "Simon J. Gerraty" X-Mailer: MH-E 8.6+git; nmh 1.7.1; GNU Emacs 28.1 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 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <74366.1677113349.1@kaos.jnpr.net> Date: Wed, 22 Feb 2023 16:49:09 -0800 Message-ID: <75057.1677113349@kaos.jnpr.net> X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: MW2NAM12FT070:EE_|SN6PR05MB4047:EE_ X-MS-Office365-Filtering-Correlation-Id: 285a7dfd-3b78-4223-c82b-08db1537eb7b X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: KKahbT1E0JchnjfuQZamrUIp4a5jw16tR8TlcPdpIxx+nAWZEfU6Nl1RZNuYdYCxiJZ9LaZ8H3il5kL8hw8obxhf01L71oi7lCHESfkMOistCCJKW9JjbaTxQSYQnGlgaffKV/Pffusk4Lty4hcSMEd8XHBAxY7kdtswTUygMq22i9xPqIpuMQQVea1YivMXSWXLIjRbIi69sQZTKMVFz1Rw6T1HimznDNe8pPfBfvm0K5BDdVqUD+bV/8kHsuMfMuJnDG7R0Bgv+scHelukWox5R1Aa6mZTqtzZNx/HdH3rwZ8zvC2ADJr6hc6xYZMhIybZcBnX1OjeTnRJO+O43LKN09EUwxtd8zOH7qWp5W8s4wtO+TDSeLxkS+oheVKxZGx0qP+ZfwZFgsr9ezJAGyp91d+70MxpMkL++TYGIIipMi2l5zLVvaCY1P806M0jUC12FRiK+2mHIIJTccdO8zwiY0/6lTMrkZYNF1OMeWhaacHmDpbhEfoUI31h6d5xG2KCRIRqmaxU8E35iI6AFO9R1MWLbtNWTdBrDLAWIjQ7hima7ZYFmNBlbiGTwWAmtkakiDajr0fLqe78Mn0mQyhK1Ar06fFYNvYCZwCujAlRn0I5UFxx7S5dbro3MII0LrHg9eTUsv7rbn3yPvXBhM/0A2duKNFvOr+/2KOAiNpFu9aNhMVnMGvCF3GH2dlG3uaUYnMFDCWXza2Uk10tSA4HzRGAfprkz4IPStoCT8GhR0Iv/iDh+B9neethJbV0ABVhYJXlgYOSR7ADYa0QVA== X-Forefront-Antispam-Report: CIP:66.129.239.15;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:p-exchfe-eqx-02.jnpr.net;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230025)(4636009)(376002)(346002)(136003)(396003)(39860400002)(451199018)(40470700004)(36840700001)(46966006)(7696005)(186003)(26005)(6266002)(9686003)(82310400005)(336012)(6916009)(7126003)(478600001)(55016003)(47076005)(86362001)(8676002)(70206006)(83380400001)(70586007)(107886003)(316002)(54906003)(41300700001)(8936002)(4326008)(5660300002)(36860700001)(4744005)(40480700001)(82740400003)(2906002)(81166007)(356005)(40460700003)(36900700001);DIR:OUT;SFP:1102; X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Feb 2023 00:50:12.0730 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 285a7dfd-3b78-4223-c82b-08db1537eb7b X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4;Ip=[66.129.239.15];Helo=[p-exchfe-eqx-02.jnpr.net] X-MS-Exchange-CrossTenant-AuthSource: MW2NAM12FT070.eop-nam12.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR05MB4047 X-Proofpoint-ORIG-GUID: Ar_KcpBefv6Rp-82RTc1SfsvOBqFePes X-Proofpoint-GUID: Ar_KcpBefv6Rp-82RTc1SfsvOBqFePes X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.219,Aquarius:18.0.930,Hydra:6.0.562,FMLib:17.11.170.22 definitions=2023-02-22_12,2023-02-22_02,2023-02-09_01 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 bulkscore=0 clxscore=1015 impostorscore=0 adultscore=0 mlxlogscore=867 lowpriorityscore=0 mlxscore=0 suspectscore=0 priorityscore=1501 spamscore=0 phishscore=0 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2212070000 definitions=main-2302230005 X-Spamd-Result: default: False [-5.10 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; ARC_ALLOW(-1.00)[microsoft.com:s=arcselector9901:i=1]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[juniper.net,reject]; R_SPF_ALLOW(-0.20)[+ip4:67.231.152.164]; R_DKIM_ALLOW(-0.20)[juniper.net:s=PPS1017,juniper.net:s=selector1]; MIME_GOOD(-0.10)[text/plain]; RCVD_IN_DNSWL_LOW(-0.10)[67.231.152.164:from]; RCPT_COUNT_FIVE(0.00)[5]; FROM_EQ_ENVFROM(0.00)[]; FREEMAIL_TO(0.00)[yahoo.com]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:22843, ipnet:67.231.152.0/24, country:US]; RCVD_TLS_LAST(0.00)[]; RCVD_COUNT_TWELVE(0.00)[12]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; RCVD_IN_DNSWL_NONE(0.00)[40.93.10.32:received]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FREEFALL_USER(0.00)[sjg]; TO_DN_SOME(0.00)[]; FROM_HAS_DN(0.00)[]; DKIM_TRACE(0.00)[juniper.net:+] X-Rspamd-Queue-Id: 4PMZFV4KH2z42yX X-Spamd-Bar: ----- X-ThisMailContainsUnwantedMimeParts: N Mark Millard wrote: > Since some of the paths reported ended up being links > (symbolic, as I remember), what are the principles for > which form of paths should be the basis for paths in > the likes of: > > .MAKE.META_IGNORE_PATHS .MAKE.META.IGNORE_PATHS > .MAKE.META.IGNORE_PATTERNS > .MAKE.META.IGNORE_FILTER > > Target of link? Path to the link itself, not the > target? Both? These all refer to paths that might appear in a meta file. They are listed in order of expense. .MAKE.META.IGNORE_PATHS is a list of path prefixes , eg if /tmp is in the list then /tmp* will be ignored .MAKE.META.IGNORE_PATTERNS might include */tmp/* which means any path that patches that will be ignored. .MAKE.META.IGNORE_FILTER is the most expensive but also the most flexible. Eg you could have tA:N/something/*, then anything that has a realpath starting with /something/ will be ignored. From nobody Thu Feb 23 01:18:45 2023 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 4PMZvh6cRjz3sk66 for ; Thu, 23 Feb 2023 01:20:16 +0000 (UTC) (envelope-from sjg@juniper.net) Received: from mx0b-00273201.pphosted.com (mx0a-00273201.pphosted.com [208.84.65.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.pphosted.com", Issuer "Thawte RSA CA 2018" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4PMZvh59Mxz46vC; Thu, 23 Feb 2023 01:20:16 +0000 (UTC) (envelope-from sjg@juniper.net) Authentication-Results: mx1.freebsd.org; none Received: from pps.filterd (m0108157.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 31MLAh9o024098; Wed, 22 Feb 2023 17:19:54 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=to : cc : subject : in-reply-to : references : from : mime-version : content-type : content-id : content-transfer-encoding : date : message-id; s=PPS1017; bh=j9lIQJugf5KHnTLcw/fk9AYgXyooL/daNgyjNUfQkOk=; b=y6xxx3FB9olWbmSnV3i59ULGeVY6qElTEpUmJwMU+n3ocjfxvWisfeMDFKd44cBN17jC 3+opqt1YTDcU+tqipcf3xR3S62Q5sPyp91Qt0+J60jz48unTFyjawt4SJ6gnKSO5BdmJ dGEmVFS+zED+mWxECXZ8twNsXCXMNb07yUlJdc5U66AFiBPKk2vbP3iSxPCjRZqlRet9 zYxTVyno2t0D4hejPWHwZKAeK7tR2MZwdQOHq6SHrVjLeAJBkQW2q1N+58uoNcTkdG0U zecahgtQWTOQQarn/mz68uHl7L77MyZcjzIgpfKzFIvbozXIV34JolbD6Vtt4wtNxSMG Ww== Received: from dm4pr02cu002-vft-obe.outbound.protection.outlook.com (mail-centralusazlp17013033.outbound.protection.outlook.com [40.93.13.33]) by mx0a-00273201.pphosted.com (PPS) with ESMTPS id 3nwkgc1ag0-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 22 Feb 2023 17:19:54 -0800 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=HSaI83C9Pcw45yqPSWYke5bxFGoBUiPwqrlbWABpE99RKoiVpkEMvmKSeAJDRzkjS08Cp86RYc/O0A4E3jV3kYgULMGu0UebFxXQZCBDf0Q/RRirUcviK3HcCDFb9rmI2L3bgAagS02MMRprC4f8CPgMmAhkY3kvjvj7Kz3JUtYDZIJyv6L85QpDWdP8mQRB7lqF9imd7dlAVzp5Ny7c5Sr3AKfKnI7zHD0YMxQ6doj2Qv39qjhsohsMKuIKsIIoDHBcHs2dh/b7fqjORsjrj/dNd+nt2y/Y+0V4ZN+I/Nfh8IzWgOHrjV3ApOutffoI5aImISZJylhh8nWtYuD+hw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=j9lIQJugf5KHnTLcw/fk9AYgXyooL/daNgyjNUfQkOk=; b=jWlh/koQjprmmo29Suht+GQ56zSRI+TGKiSxAuNvu3CzAZxPKIdMz+T5bpHXx5DkHh9yh3WTTUuxiEizLbRr1adp0OKqWCEZceNQ7uy4JZmO/bZ2ymY3s//mwSK5sEvPGXnadm3Fnwbmsx+w5j0bVP134OC8H4ZuZnWA1hymksVQoo49YoElgRzmYsnIxd5SerFe8i+i7MG0eG/h5vILPxm3naLUXIO1fRjeZhEDOj9sRGzlvJeos9bYXuIeS8AfLJ9NjR1o+RYITUBNz7uOohA9zGctWbRKUAvxxG+lQ21BRMdeISjTfgejzMLcyEIkvDzcR5kTn31KMv4gzJavRA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=softfail (sender ip is 66.129.239.14) smtp.rcpttodomain=yahoo.com smtp.mailfrom=juniper.net; dmarc=fail (p=reject sp=reject pct=100) action=oreject header.from=juniper.net; dkim=none (message not signed); arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=j9lIQJugf5KHnTLcw/fk9AYgXyooL/daNgyjNUfQkOk=; b=UWPu/6qwG77TKwBn3ODe5+DrFa0uc+easFl260pObZJSQFUQxlp3th8bCQjizJ2+lTXMNR9FEgAfOhHSwka6aynb6j5CQPC/vhe9CfAaQsvgpTQnHqDF5W3SWY6zLJpI935pdtrvood1QV5hvIYK34KrvUMMuy7L7tQu4ICDcvE= Received: from BN8PR04CA0063.namprd04.prod.outlook.com (2603:10b6:408:d4::37) by CY4PR05MB3512.namprd05.prod.outlook.com (2603:10b6:910:5a::39) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6086.23; Thu, 23 Feb 2023 01:19:47 +0000 Received: from BN8NAM12FT073.eop-nam12.prod.protection.outlook.com (2603:10b6:408:d4:cafe::60) by BN8PR04CA0063.outlook.office365.com (2603:10b6:408:d4::37) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6134.19 via Frontend Transport; Thu, 23 Feb 2023 01:19:47 +0000 X-MS-Exchange-Authentication-Results: spf=softfail (sender IP is 66.129.239.14) smtp.mailfrom=juniper.net; dkim=none (message not signed) header.d=none;dmarc=fail action=oreject header.from=juniper.net; Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.14 as permitted sender) Received: from p-exchfe-eqx-01.jnpr.net (66.129.239.14) by BN8NAM12FT073.mail.protection.outlook.com (10.13.183.168) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6156.5 via Frontend Transport; Thu, 23 Feb 2023 01:19:46 +0000 Received: from p-exchbe-eqx-01.jnpr.net (10.104.9.14) by p-exchfe-eqx-01.jnpr.net (10.104.9.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.30; Wed, 22 Feb 2023 19:19:45 -0600 Received: from p-exchbe-eqx-01.jnpr.net (10.104.9.14) by p-exchbe-eqx-01.jnpr.net (10.104.9.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.30; Wed, 22 Feb 2023 19:19:45 -0600 Received: from p-mailhub01.juniper.net (10.104.20.6) by p-exchbe-eqx-01.jnpr.net (10.104.9.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.30 via Frontend Transport; Wed, 22 Feb 2023 19:19:45 -0600 Received: from kaos.jnpr.net (kaos.jnpr.net [172.23.255.201]) by p-mailhub01.juniper.net (8.14.4/8.11.3) with ESMTP id 31N1Jh4t016911; Wed, 22 Feb 2023 17:19:45 -0800 (envelope-from sjg@juniper.net) Received: by kaos.jnpr.net (Postfix, from userid 1377) id 5A15620A55; Wed, 22 Feb 2023 17:18:45 -0800 (PST) Received: from kaos.jnpr.net (localhost [127.0.0.1]) by kaos.jnpr.net (Postfix) with ESMTP id 5799920A54; Wed, 22 Feb 2023 17:18:45 -0800 (PST) To: Mark Millard CC: Bryan Drewery , Current FreeBSD , Peter , Subject: Re: FYI: Why META_MODE rebuilds so much for building again after installworld (no source changes) In-Reply-To: <76FA98EF-6184-4D7E-A01F-0EE8117D0D10@yahoo.com> References: <3345EBA5-A09C-4E3F-B94D-39F57F56BDBB@yahoo.com> <73088.1611797582@kaos.jnpr.net> <10819.1677108389@kaos.jnpr.net> <76FA98EF-6184-4D7E-A01F-0EE8117D0D10@yahoo.com> Comments: In-reply-to: Mark Millard message dated "Wed, 22 Feb 2023 16:40:26 -0800." From: "Simon J. Gerraty" X-Mailer: MH-E 8.6+git; nmh 1.7.1; GNU Emacs 28.1 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 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <28362.1677115125.1@kaos.jnpr.net> Content-Transfer-Encoding: quoted-printable Date: Wed, 22 Feb 2023 17:18:45 -0800 Message-ID: <29887.1677115125@kaos.jnpr.net> X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BN8NAM12FT073:EE_|CY4PR05MB3512:EE_ X-MS-Office365-Filtering-Correlation-Id: a4829c32-a154-470a-3032-08db153c0d13 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: TTTCv9GIsYqN6CKhITFe/PTVZiAYmrGw+PM0xGQ0p7BxEp9VixlZroRAf1MF7olh3iIDpQpoBm9ltlZYK/ecS0v8KupLGW5nlLSl8YUt437H5i9ooi6QmLsUdBTEn+2m0FMYNBails1jfg4SiAyhs0w765zDhidhjkREYctPpmzXjSkel5FwDoey+mftoKZOsDJehDe936MUMITnb9/LqqQmeX2DYCLkbZYB1MWsTMhNuqd/OxcKBHI4xyBeQ9VFite24xdANSXRsc+5hZjvT8qiWn5MCgbSXmkCjoLbtk5W91AeLf5wmEUDL42IhaRSsc/bDgfknX1kVAMB4IFPrA/WKrgxDnYO6J3rf1MvFKOrovcwLcDr0KNV3GEDQ4oOINxWTIRmuwGliZph0tnWaB9k1X8ZbAug649/012Z4KstdSUCGvx7EEeRhTl+AYM6aYpA4nfJ95gS+HDXCcElSXiMgEGYe571Cu2x2M0VACbuJYzZMS+9s5umfNRB9YU+ThiF08f76C1MDUvHkvgrbQeNsv+6eqfHMGXVm9vnz4yRSwui5hFSJSI39yBiS6Ug8LkgSyO1VTYUnu0UCEZpNxoYGA6FutBh0hU7K14gwuWFV8x6tmqVeMgizwR8a7CF58iyzJukBSkZeQEIQuVDwOu2bYQHwlTWNea7ycREjOw8FagfHkITOMZOnynpUihg2WhsPNrDze9eBzFmqyDfGBcotrX7iZzYm6pEakonOKg++Z2KFyAQuV5I+TwY2vQiJRaI7s12KWxwBopP12uzaQ== X-Forefront-Antispam-Report: CIP:66.129.239.14;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:p-exchfe-eqx-01.jnpr.net;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230025)(4636009)(136003)(376002)(39860400002)(346002)(396003)(451199018)(36840700001)(40470700004)(46966006)(356005)(81166007)(40460700003)(2906002)(26005)(6266002)(186003)(9686003)(82740400003)(107886003)(36860700001)(5660300002)(7126003)(8936002)(316002)(478600001)(41300700001)(70206006)(70586007)(55016003)(86362001)(4326008)(336012)(6916009)(8676002)(7696005)(82310400005)(47076005)(40480700001)(54906003)(83380400001)(36900700001);DIR:OUT;SFP:1102; X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Feb 2023 01:19:46.3233 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: a4829c32-a154-470a-3032-08db153c0d13 X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4;Ip=[66.129.239.14];Helo=[p-exchfe-eqx-01.jnpr.net] X-MS-Exchange-CrossTenant-AuthSource: BN8NAM12FT073.eop-nam12.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR05MB3512 X-Proofpoint-ORIG-GUID: eIGPk0ecVQ1NbD9cL7EDREDFOf9BOcPW X-Proofpoint-GUID: eIGPk0ecVQ1NbD9cL7EDREDFOf9BOcPW X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.219,Aquarius:18.0.930,Hydra:6.0.562,FMLib:17.11.170.22 definitions=2023-02-22_12,2023-02-22_02,2023-02-09_01 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 mlxscore=0 clxscore=1015 priorityscore=1501 phishscore=0 mlxlogscore=807 bulkscore=0 suspectscore=0 spamscore=0 adultscore=0 impostorscore=0 lowpriorityscore=0 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2212070000 definitions=main-2302230009 X-Rspamd-Queue-Id: 4PMZvh59Mxz46vC X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:26211, ipnet:208.84.65.0/24, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N Mark Millard wrote: > Thanks for the information. > = > > strings `which bmake` | grep META.IGNORE > > .MAKE.META.IGNORE_PATHS > > .MAKE.META.IGNORE_PATTERNS > > ${.MAKE.META.IGNORE_PATHS:O:u:tA} > = > The -dM output's "is newer than the target" lines > show the path from before the above transformation. > (The :tA results possibly could use another > sort/uniq sequence for the realpath results?) That indicates the above IGNOREs are not working. > I've been pondering things because, so far, my > attempts to experiment with this has failed to make > the -dM output lines for the paths go away and it > still does the related build activity. I've been > trying the likes of: > = > .for ignore_legacy_tool in awk cap_mkdb cat cp crunchgen crunchide dd eg= rep env file2c gencat grep gzip jot lex lb ln m4 mkcsmapper mktemp mv patc= h realpath rm sed sh touch truncate uudecode uuencode > xargs Is there anything under ${OBJTOP}/tmp that you don't want to ignore? Otherwise you could simply use .MAKE.META.IGNORE_PATHS+=3D ${OBJTOP}/tmp/ You might need ${OBJTOP:tA}/tmp/ or both. > .MAKE.META.IGNORE_PATHS+=3D ${OBJTOP}/tmp/legacy/usr/sbin/${ignore_legac= y_tool} > .endfor > .for ignore_other_tool in ctfconvert objcopy nm > .MAKE.META.IGNORE_PATHS+=3D ${OBJTOP}/tmp/usr/bin/${ignore_other_tool} > .endfor > = > in what I use for make.conf via: > = > __MAKE_CONF=3D/usr/home/root/src.configs/make.conf > = > It is using paths that match the -dM output lines ( sbin > use despite sbin -> ../bin being a symbolic link). > = > Note: WORLDTMP is not defined that early, thus the ${OBJTOP}/tmp > use. > = > -V.MAKE.META.IGNORE_PATHS is showing the paths I would > expect, matching the -dM lines. Do you have example? I really need to add some unit-tests for these... From nobody Thu Feb 23 03:47:41 2023 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 4PMfB55g6Vz3stR7 for ; Thu, 23 Feb 2023 03:47:57 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic303-23.consmr.mail.gq1.yahoo.com (sonic303-23.consmr.mail.gq1.yahoo.com [98.137.64.204]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4PMfB50GLHz4N9B for ; Thu, 23 Feb 2023 03:47:56 +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=1677124074; bh=VfFiIFbLfvmjLBr+M69oY9f2j0dRKALKTOlnezAoGvw=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=DAGBh+PnqyeLkPZ2zIkuUixAya0wmfsCd4Bt8MV2mKX3Gozy4GpsizSsTBrR2nJclG24hHO0XYiHFwfeg8LHZFdgn670bVEZY/93lENdKPe1eQq/aiw3i4GOMhNfNeoAMOzG3hPf9FnbS9ANJ/G6ohhl161LjU6cbETnN7znaMc7QGloGqKQ/QSHNn1kaZcpIX5ywFwB85I/WZ53tCLEDwV7sdDWz3DS6nWj/ASkYBO/gY+9QUq8VXjoTEoVsK8Ix7eUupP9U5B1t8/fRMBynMJ/ZMKUs2X7l0H1ZGkOnhxWEuP1Mg7GpZK5yDcTLUO5NoUz1NdOowv3KqRGTIOeiA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1677124074; bh=JscS5y8s1CN3CVx0SDMShL8UYfXwTpFDKZOFv6JCQMt=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=mxsBedNmnNlL8sCkxaxqrBYE0VfYkcphNbzR9J+Wel9/rE2mF27BaTU05hTOZ6qPJ8KtjERnJXdEr7HvCsjLqX/kLGtZveCQoQ24sLmWNC+VIsTZ6zCBZfn4emNciNHeEJbGe53w1z+j307OYi0TQ1nPBAFbfK/8FaO9C8UGS7s3SymjibHoY8l2KH2QgJj/5AoPm132yFLWeAMhBaHs9YG21+G2yn6/ywbUfc83ZwtRGg/RP6qbNWfgUGTUwkvX+fA1kBvSbv6wT97eEtgoCVNJiSPeiYDiirwRhp4sOJzp+rC9h8PbF/ZN4AIyRPEi8Kg6m5MK+d2KuVDInf48Lg== X-YMail-OSG: UXPFaG8VM1lhxMGnm1OqxChJ1ax_u0ABYTVbu9oDWcI4ncEK.yfCPZ7eMZL8tiZ 9mTYJUiCdxtpZDyoTjqjhCEXVvOcdxmX1fhsQcxB1k6VVIj7HPGjVPWJ9RLv0Bb35FGuCYXpC8Or 5ZXLlYpfxhMsXwHLLIbEMOFgvBKD3xXjfmcEcV1FmKOFgd5PMeQldJLT4mXx5adI5n5sIBTw5EG9 Wif2octrFIk3KHdJpx3X1rsrWm8Qaw6fBkO3iH6Sympqzzk3lRvSA3jtXFsh3PKVOcSeljesOZf7 jjVBOdckC585qLR_ovbqwdKIZh6e_ukM5pCroRO7wT6lQqjtijGr9Jh8iBpsLb.zHSgKUS.rTawV Cs2vXWGfe663YTX0mFuU8TecnFacG.nPBInulN1u0lv2H1Gb7434iNj_i4jA8WXQ74qIQsYVhSnK 9rd6L0TfHGC.Kndk4c1B_zpVlobq6iU8Ef3l18AwvLXQkld8qK_3Bi2DZW_3BbdYRS4wRy6bEamG r7slIzA8YP5cM291gS4ykm_Am2NFkjl1v3iMR.WwW9WsseiprKUEvB0JnBaVXc.wvwYNjWRVXZIX 8C7mQPcZVTxh3cH1UIEFxXRiZRGIFIzwwQgbz0dtQnCUqdloyMdHlvmA0F1fRfRQb_ykE0UlHWFI Z_ICc3SFuua1U9z0Xj_x_YkRj_exJO7OyTIhZ6XMRiANrPQOOESTJoeOZTqCp0ZZewHSsMxeh5i9 p5w83oB6wo.yNHzox2_U3i4UjBNqEkUP35J1M6QwNB7bVxfOFX2kqh2WlPTA3IM2QeSsSObsfrur EU7UWdOFPtZvqfpkThI2j6AViZVxGlsBhikIBfawWpVoR_pGOwlrAPWnZogn6cmtCDpsFi.27cU9 YF3YVipge63QobFc.2M.WXcfieligSmNzjUJJ2o642ZlrwuOqHt6MHrlWwZU2XwErsfF.MhZqYVW eUG37aJX7RnquXUtaqTzs0VWyJw8RBpsvxo2wcJuraXYanJNxc76c95ZGvPsHv9vSfiDoMlRdY0f Vi3tCcK0Xv7CE._Qz8EmbsJMj3snLZzDMM_5790Tj8QGP5Io6NS2h1AH0BMfwucmZcvvjzHREZi0 VIcsnw9yHa.cF5HVWq.6G.i6W4onhNKfJVmO7mKFvvKzb_59v05KhW8nAA3QeAhx3w2Dh.FSiyfK IflbgLV02yryO2bnLiDk3K0NkeDxBARIpNnHIEP0TaxgEOWjfusqttoQ1oUOEkxPaoTWD5n7jHf0 7h7NlXSe4oKalo2RTtikwj_QcUDwkddO6vdI_Y0GoT8uyddbFxqgBHs.nrlRTBrKs0.WFxf_6k.V F6MiKzjM0izokfTwMFdmQ9spKFyGy0e7cA3tq712hTH4QTTZ.Z3PC9jGpV3mw8aj6LETqrNbMk67 HxbzqC3KQRhVamKTafN6c4f7WTJZwhD0TzwWr2u3xX4ORwXKG3g9_M1SdvkJNVGExvaM2SJF7RVR E6dMVxXU10i9tf8h04g5qZ_m0LuYHf1cknRK0C53M_CPc9v606vLlao1szIuJPZYJHojTEVjJ1Jj VII3r.N8UJu3tW9zxIPlHQFTylz3LIiTbdR0.yMoDz.LEfekro4fRjPQPaifRKNDJrVKNTrcyc7x uSjE1sNV.bE0vwY9a8_D8SHCA4SdqX8PJaUcV9qKLgM96.HMr_.9pYffbEw8TL8pxe8WPX1KqjCB xPpwEeP9wMv641X0jyLSp32CEM.GdWsCFTqyuglHRVJhBzn72zQGDliEVT1GlsY7gJ6YZSYr_wsN Qn.m.6GYqLdTreqQMaQODapoVlEabp70JKoKSW9XuK.pJhtgkUUgReXP8xxgkNzNpp5nYAiPPK2H NHos1mIY4mqby0NCx55gv6x9I2pcublvjCs2_A52sNhktCFfai2IGJ3QOHzqU1dgp5v3ZcvZPk6B __PjdIWtHPQiewLDuow6J.nD1vA5lZHvpJMqaJ3r1Jt0OB_h6hTp.91I9tGNEop8dD9W49SsQXIt GG6nVxKMW6BujTXKl8tCFzcnafJ4111XpI4e6qGfMtvmDQnDc6ksw553NAQ9_o9RMh4MD4pAJR1G EDf6NF2NWrlPU98YPLxKIK0eNDhWwycoi5zKNvKTQTcxlz2Uze5.CRlZ5uFiBcmcGMMM8ixp3K3s Q9EgWOsd6HocoqYw5tCSLknWhKD8OYn9onQBSMlAP96S1i6_DokPld4ny9yaMQ76.rTiEhAVEYD7 AUykACoNae6oAkajmu8miQPt3WpIFRumsaOEaAMbrv3g4uhqheGtulYfsuQi63zTjhogFWZz5YdG MFw-- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic303.consmr.mail.gq1.yahoo.com with HTTP; Thu, 23 Feb 2023 03:47:54 +0000 Received: by hermes--production-ne1-746bc6c6c4-j9j2r (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 914d2b54f1ff303de312eb1a65bf9824; Thu, 23 Feb 2023 03:47:53 +0000 (UTC) Content-Type: text/plain; charset=us-ascii 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 Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.400.51.1.1\)) Subject: Re: FYI: Why META_MODE rebuilds so much for building again after installworld (no source changes) From: Mark Millard In-Reply-To: <29887.1677115125@kaos.jnpr.net> Date: Wed, 22 Feb 2023 19:47:41 -0800 Cc: Bryan Drewery , Current FreeBSD , Peter Content-Transfer-Encoding: quoted-printable Message-Id: <27790339-240F-4C97-97C7-38AFD8DE03D5@yahoo.com> References: <3345EBA5-A09C-4E3F-B94D-39F57F56BDBB@yahoo.com> <73088.1611797582@kaos.jnpr.net> <10819.1677108389@kaos.jnpr.net> <76FA98EF-6184-4D7E-A01F-0EE8117D0D10@yahoo.com> <29887.1677115125@kaos.jnpr.net> To: "Simon J. Gerraty" X-Mailer: Apple Mail (2.3731.400.51.1.1) X-Rspamd-Queue-Id: 4PMfB50GLHz4N9B X-Spamd-Bar: ---- 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-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N On Feb 22, 2023, at 17:18, Simon J. Gerraty wrote: > Mark Millard wrote: >=20 >> Thanks for the information. >>=20 >>> strings `which bmake` | grep META.IGNORE >>> .MAKE.META.IGNORE_PATHS >>> .MAKE.META.IGNORE_PATTERNS >>> ${.MAKE.META.IGNORE_PATHS:O:u:tA} >>=20 >> The -dM output's "is newer than the target" lines >> show the path from before the above transformation. >> (The :tA results possibly could use another >> sort/uniq sequence for the realpath results?) >=20 > That indicates the above IGNOREs are not working. >=20 >> I've been pondering things because, so far, my >> attempts to experiment with this has failed to make >> the -dM output lines for the paths go away and it >> still does the related build activity. I've been >> trying the likes of: >>=20 >> .for ignore_legacy_tool in awk cap_mkdb cat cp crunchgen crunchide dd = egrep env file2c gencat grep gzip jot lex lb ln m4 mkcsmapper mktemp mv = patch realpath rm sed sh touch truncate uudecode uuencode >> xargs >=20 > Is there anything under ${OBJTOP}/tmp that you don't want to ignore? More than just _bootstrap_tools_links entries end up in ${WORLDTMP}/legacy/bin/ (so in ${WORLDTMP}/legacy/sbin/ via the symbolic link pointing to ${WORLDTMP}/legacy/bin/ ). So: yes. Also, OBJTOP is not constant over all the parts of buildworld buildkernel . Having the late-substitution form of notation ${OBJTOP} might not be appropriate for the content of .MAKE.META.IGNORE_PATHS . I'm trying to figure out if there is a stable way of getting a path that would not suffer variability via late substitution.=20 > Otherwise you could simply use >=20 > .MAKE.META.IGNORE_PATHS+=3D ${OBJTOP}/tmp/ (Ignoring the variability of OBJTOP issue . . .) I do not expect that would work: ignoring things it likely should not. Also, I'd rather grow a smaller set of ignores gradually to make it easier to detect if an addition starts causing a problem and can be backed out. Starting with everything ignored would make things much harder to figure out when ignoring creates a problem. > You might need ${OBJTOP:tA}/tmp/ > or both. >=20 >> .MAKE.META.IGNORE_PATHS+=3D = ${OBJTOP}/tmp/legacy/usr/sbin/${ignore_legacy_tool} >> .endfor >> .for ignore_other_tool in ctfconvert objcopy nm >> .MAKE.META.IGNORE_PATHS+=3D = ${OBJTOP}/tmp/usr/bin/${ignore_other_tool} >> .endfor >>=20 >> in what I use for make.conf via: >>=20 >> __MAKE_CONF=3D/usr/home/root/src.configs/make.conf >>=20 >> It is using paths that match the -dM output lines ( sbin >> use despite sbin -> ../bin being a symbolic link). >>=20 >> Note: WORLDTMP is not defined that early, thus the ${OBJTOP}/tmp >> use. >>=20 >> -V.MAKE.META.IGNORE_PATHS is showing the paths I would >> expect, matching the -dM lines. >=20 > Do you have example? > I really need to add some unit-tests for these... You may want to wait while I see if I can come up with a better example context to show things. I only just noticed the late-substitution potential issue and started looking for a way to avoid it, for example. (Either a value that does not vary or a form of causing up-front substitutions in my make.conf .) =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Thu Feb 23 05:09:54 2023 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 4PMh0y14Qzz3sywX for ; Thu, 23 Feb 2023 05:10:10 +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 4PMh0w1XYHz4Y7S for ; Thu, 23 Feb 2023 05:10:08 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=SonYrXoK; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.148 as permitted sender) smtp.mailfrom=marklmi@yahoo.com; dmarc=pass (policy=reject) header.from=yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1677129005; bh=33+qL4ysoOv5xjzOEquo+PuFD2l6lAW5DeaWbnf0YSc=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=SonYrXoKnTNYnNEryFuOdKoMPmok/BErTHQ+Yov99Jtzahhc4giYNMYrX9qaHquTtg9CWIDjsec9w42SoXYcHT6Vg9+RCrdtwbvLTnnjFVhw2bdjNtTBrm2sBhxhUUEdQPLO2fuhWstGK/T1+we+B8ezUo+SvN/T02F+W3wBmP9uPxsW0uXn1hHsUPCai166151tQyssVTy8s8lys4d4O0l2rh8XkynsAO+9430iE0LDeuMVTqheD4Ead7Stm7+rqVBESh7ElCfU7bUUZYRsm1cgsF+yACGccBoPKygl9IbAOcgJrapVUqBQHy05QZL4DHIw0aWmb1VvrDsLYJctmw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1677129005; bh=rOsbY5aeuiCMk3AJ0Co6jLVtPMZ5xARGcB++shROzcC=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=CW0BOixa+7NqA9YJ25IzEQg0DH6BP9ilqNb5x2Q3Rvbu9hLBjAi8eUkJW2su6BcGaxWEqh74I2ny8uZtur4hLZmsw4LWhltQmmYJNczMq5ilBHy8qUSNYI8W1G5PsF/6itqKoCy23Z76NR1mx7yMgw/FGXqT2NPJz32z4uWEqZ3erolM8TMQJlGJeFSa5/I3WfsgdbjlkklkKLpcJS1PK8fjOE1j9zcjhwmYRRQgp6CY7r5Eb2UDksn505sZI1WAGVg+BMDUzLHPHY6BGZeVH48ptk4napCvkTIl/gaDH6wyn2+Wkh8pnIQcHyI0ez4QYs7TfSLoPBvN1v3/Rw4Pog== X-YMail-OSG: qu_ILrsVM1ki7uhUWojsTsoApFR.1kUpzEwEupQAeA9KXIr72KLennCGBPuF0CC KlJXB6tAtDYLgWmv6wIVGjaChGVXOtbZUZXwuEmh_U62sr0cHn0iUp6OR.nz5bq.rH3XJelK9rOG P31EDp_IaW_U33_65AkipXqkj8P9YcH.IRgklTWQ3tER2T8VKIzioGtPgPbZQWUU5juLF9zbfXbo 02dDqglKWgdujMtvd435_ZFbiN.rtkNqm.LqTFtZg1CL2TJSRE3jJN4.P8C13Z7xIowT7XkLGVIE Ln5hD9dNw.rNud9H.FmfFSdd4LtRcxIoGovNT3_VdXQZQIJHY0tfyxZjTemS_1WQHUakCVN8iivN xH5gnit7wYjYacPfAieSuMXPO.44TgKR1YPeOtPhL.UA9M1TNArDlCnyr6uQVrqcf947FzvQm2it jVJ3Kv8..HD30y6LT0gufXa6J3ZlH188ltm7EWqdexKn4fGvbKAsi36B3dIKPM6O4fUSVbFErs49 J8xi.fZKjrmbrbEQ90PG0IweFuCk3kPywDogNCBbIa.flEe.ivULZt3P1Q3Kg5Gma4gwMCQpqWMw EepJobGZuCEdk3.zGwPxYPrATpNArwjicqzkPloWNhFhDTrAJ87C2eoCW6ub755iKqrgO_sAKqB4 KwVWKCUnqaGfC_A1EE6kDsfwEBgqEy2EiSDihSAciHXiZWdKOB2y8IpOYNiD_9nCgZfP32hKeWj5 y6kilOrmB.KYCFDoRadbGyA275arfM4dIJHNO17fieOTye_fTvyDWsNSGpJEvMVxVaTHq_uoljBj 1HB02dEd7Cf7S9pXED1Z0I3bgHKGh0rVgaAkmasXPNPvnchKNLQPUcptRsokZrxmmSLeFZXCgN_a 6D0wj5hqArAF_XdFHu_IeX2w1eycQgNteUYtaf6ZDa0KCuXUQnHpsYY8aHnzIKRVqH2.h5mor1N_ 4EeP.g34FSb2H5S6XAgKbjFh_MAy_YZBR4WjBB4TUM5ICAuLwOGN1B_l4iNeMFxnJmOMF30ncc0_ qb.BR2qwtuILmFriQeHAtTpoydS5zcI.By2SVPtzG_J9bcDnxM08GLRjkedJyFDO_Yz2kXm94ZTo dyfazSRzAgmjDfwKkeTHrgnndXPDOamyviU4IveomTz6vdlaI_V0vLPIw3SBLS97ziWHX2KGWLJb UriyiTDzN7DPnfeVLX03WNo8Kec_So5do0jTL_jfu1Hg5hBMeYQ84CFEPu0bqM.hfWTF2zhar67d rO4SfaP5pNfSnboTBBj023p6HIerxGXfHES9QsWsEvjBfny0Ldazeekeg.ajc_Qq491lW4.obVg2 DDFyj1KZs1lv1_PMNRw.L2od7h2.XO4ATaWP.9mX7Eq.0_19IxrVLLehdtRUE2T56Fa6FXrHfVQU syGldFQiTE7O3VIo44NNTOxyT4Fj_0a6CerilOlp8cOtDJihPVtVBRUKPsnqvp2iaKZAY4c5hlfy N7buPZJTcd7c96c7EG6PKZufwsEpoGS2xnQSOPivJ8BrDLJUGoiREouRSf.lK9CTJgficOXSedWH EoIb1bT6PU.NgrqvFZSrQLN_X7buzMRQG_IKmE5WQk7G040_rd3IDt_4jZQAEBADIz2w_flj7mZR 0zma3c5OhIc6or4lL4ENI5Ko.vkYprMvKxjhDoByTWHyNwNT8OaHGcDXev9RwfpYHcNJUTENk0ou lPpgHu4x3kE4BAUUS_jRvatp5b9P0ZVhbeKllxqRGGywiBC.5lH03Shm0WGXoM4Z03sJ7N6gHSHr L71ZD9puRRCWlQvEHe54SvD5iSchPY4QQohB7IoqaaQ_9ePO09Zxv07JTkdOS3je5kfO1Eo4C_1w UlbqFzbcDaslQldMXK29McE4mJhnYxxLq6GstJzOST0i1pO.BENOWkYzMZJF_5ZbPap1VSIms_Hd tCyx1QQQQ7qfN9SQeNru_4rGLoPz0bFwkn0A7ptDUgZkIIbmPS_KWb8LcxIwOxOKUiwmgRYPyIYN USjJtCZbr9eUrSH6LowK8K_GhFLBBYKCaHB81AVaQzb39Ut8mmxPP60BSJHRG8oi09JYVBo9dVqI w_aga0A4vGy0anac1XTJSQanqm5FrO2ZztAdd1QsEo3vx58mmIzuC9KGUS9Hz_ye4mPIYNNUbQ6p Rj6pjlJT.S_a4Yo41bY.I3_DGTCClbLuDoA.RZqaqAqUA9TOohaVFcNGE_IyDkzd6IagPPZkinzj Dn9FMSNdni10ApyGo4VCpMsNs232Mw41RjhPRO3JN89I8v.XAvWwn8H0elT5gW.tWyvLhaFlVuQ- - X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic309.consmr.mail.gq1.yahoo.com with HTTP; Thu, 23 Feb 2023 05:10:05 +0000 Received: by hermes--production-gq1-655ddccc9-59dl9 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID a4e72563c9e1465c0fa374d16a1c3649; Thu, 23 Feb 2023 05:10:05 +0000 (UTC) Content-Type: text/plain; charset=us-ascii 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 Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.400.51.1.1\)) Subject: Re: FYI: Why META_MODE rebuilds so much for building again after installworld (no source changes) From: Mark Millard In-Reply-To: <27790339-240F-4C97-97C7-38AFD8DE03D5@yahoo.com> Date: Wed, 22 Feb 2023 21:09:54 -0800 Cc: Bryan Drewery , Current FreeBSD , Peter Content-Transfer-Encoding: quoted-printable Message-Id: <7FB6F619-6E71-4075-8A6C-573564371DD5@yahoo.com> References: <3345EBA5-A09C-4E3F-B94D-39F57F56BDBB@yahoo.com> <73088.1611797582@kaos.jnpr.net> <10819.1677108389@kaos.jnpr.net> <76FA98EF-6184-4D7E-A01F-0EE8117D0D10@yahoo.com> <29887.1677115125@kaos.jnpr.net> <27790339-240F-4C97-97C7-38AFD8DE03D5@yahoo.com> To: "Simon J. Gerraty" X-Mailer: Apple Mail (2.3731.400.51.1.1) X-Spamd-Result: default: False [-3.49 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.99)[-0.990]; MV_CASE(0.50)[]; 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]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; ARC_NA(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.65.148:from]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; RCVD_TLS_LAST(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@FreeBSD.org]; TO_DN_ALL(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; FREEMAIL_FROM(0.00)[yahoo.com]; MID_RHS_MATCH_FROM(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; MIME_TRACE(0.00)[0:+]; FROM_EQ_ENVFROM(0.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.65.148:from] X-Rspamd-Queue-Id: 4PMh0w1XYHz4Y7S X-Spamd-Bar: --- X-ThisMailContainsUnwantedMimeParts: N On Feb 22, 2023, at 19:47, Mark Millard wrote: > On Feb 22, 2023, at 17:18, Simon J. Gerraty wrote: >=20 >> Mark Millard wrote: >>=20 >>> Thanks for the information. >>>=20 >>>> strings `which bmake` | grep META.IGNORE >>>> .MAKE.META.IGNORE_PATHS >>>> .MAKE.META.IGNORE_PATTERNS >>>> ${.MAKE.META.IGNORE_PATHS:O:u:tA} >>>=20 >>> The -dM output's "is newer than the target" lines >>> show the path from before the above transformation. >>> (The :tA results possibly could use another >>> sort/uniq sequence for the realpath results?) >>=20 >> That indicates the above IGNOREs are not working. >>=20 >>> I've been pondering things because, so far, my >>> attempts to experiment with this has failed to make >>> the -dM output lines for the paths go away and it >>> still does the related build activity. I've been >>> trying the likes of: >>>=20 >>> .for ignore_legacy_tool in awk cap_mkdb cat cp crunchgen crunchide = dd egrep env file2c gencat grep gzip jot lex lb ln m4 mkcsmapper mktemp = mv patch realpath rm sed sh touch truncate uudecode uuencode >>> xargs >>=20 >> Is there anything under ${OBJTOP}/tmp that you don't want to ignore? >=20 > More than just _bootstrap_tools_links entries end up in > ${WORLDTMP}/legacy/bin/ (so in ${WORLDTMP}/legacy/sbin/ > via the symbolic link pointing to ${WORLDTMP}/legacy/bin/ ). > So: yes. >=20 > Also, OBJTOP is not constant over all the parts of > buildworld buildkernel . Having the late-substitution > form of notation ${OBJTOP} might not be appropriate > for the content of .MAKE.META.IGNORE_PATHS . >=20 > I'm trying to figure out if there is a stable way of > getting a path that would not suffer variability > via late substitution.=20 >=20 >> Otherwise you could simply use >>=20 >> .MAKE.META.IGNORE_PATHS+=3D ${OBJTOP}/tmp/ >=20 > (Ignoring the variability of OBJTOP issue . . .) >=20 > I do not expect that would work: ignoring things > it likely should not. >=20 > Also, I'd rather grow a smaller set of ignores > gradually to make it easier to detect if an > addition starts causing a problem and can be > backed out. Starting with everything ignored > would make things much harder to figure out > when ignoring creates a problem. >=20 >> You might need ${OBJTOP:tA}/tmp/ >> or both. >>=20 >>> .MAKE.META.IGNORE_PATHS+=3D = ${OBJTOP}/tmp/legacy/usr/sbin/${ignore_legacy_tool} >>> .endfor >>> .for ignore_other_tool in ctfconvert objcopy nm >>> .MAKE.META.IGNORE_PATHS+=3D = ${OBJTOP}/tmp/usr/bin/${ignore_other_tool} >>> .endfor >>>=20 >>> in what I use for make.conf via: >>>=20 >>> __MAKE_CONF=3D/usr/home/root/src.configs/make.conf >>>=20 >>> It is using paths that match the -dM output lines ( sbin >>> use despite sbin -> ../bin being a symbolic link). >>>=20 >>> Note: WORLDTMP is not defined that early, thus the ${OBJTOP}/tmp >>> use. >>>=20 >>> -V.MAKE.META.IGNORE_PATHS is showing the paths I would >>> expect, matching the -dM lines. >>=20 >> Do you have example? >> I really need to add some unit-tests for these... >=20 > You may want to wait while I see if I can come up with > a better example context to show things. I only just > noticed the late-substitution potential issue and > started looking for a way to avoid it, for example. > (Either a value that does not vary or a form of > causing up-front substitutions in my make.conf .) >=20 I got some useful information about one type of context that is odd and creates a far mount of "is newer than the target" notices. This is an example of something that always "rebuilds" via a . . ./sbin/realpath "is newer": = /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/sys/GENERI= C-NODBG/modules/usr/main-src/sys/modules/aac/machine.meta: 23: file = '/usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/tmp/legac= y/usr/sbin/realpath' is newer than the target... Building = /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/sys/GENERI= C-NODBG/modules/usr/main-src/sys/modules/aac/machine It turns out that the .meta file is for a symbolic link: # ls -Tld = /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/sys/GENERI= C-NODBG/modules/usr/main-src/sys/modules/aac/machine lrwxr-xr-x 1 root wheel 31 Feb 22 20:19:27 2023 = /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/sys/GENERI= C-NODBG/modules/usr/main-src/sys/modules/aac/machine -> = /usr/main-src/sys/amd64/include . . ./sys/modules/*/machine being a symbolic link to a directory is = normal. It turns out that . . ./sbin/ln "is newer" examples are tied to a similar issue: = /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/usr.bin/aw= k/awkgram.tab.h.meta: 12: file = '/usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/tmp/legac= y/usr/sbin/ln' is newer than the target... Building = /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/usr.bin/aw= k/awkgram.tab.h But . . . # ls -Tld = /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/usr.bin/aw= k/awkgram.tab.h lrwxr-xr-x 1 root wheel 9 Feb 22 20:18:24 2023 = /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/usr.bin/aw= k/awkgram.tab.h -> awkgram.h The .meta file is for a symbolic link, to a file for this type of context, not to a directory. (All the examples happen for what I'm looking at happen to be symbolic links to header files.) It appears that for symbolic links being the target, META_MODE does not respect .MAKE.META.IGNORE_PATHS . =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Thu Feb 23 06:06:22 2023 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 4PMjHV3Zmkz3t2fQ for ; Thu, 23 Feb 2023 06:07:50 +0000 (UTC) (envelope-from sjg@juniper.net) Received: from mx0b-00273201.pphosted.com (mx0b-00273201.pphosted.com [67.231.152.164]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.pphosted.com", Issuer "Thawte RSA CA 2018" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4PMjHV1J1vz3BwB; Thu, 23 Feb 2023 06:07:50 +0000 (UTC) (envelope-from sjg@juniper.net) Authentication-Results: mx1.freebsd.org; none Received: from pps.filterd (m0108160.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 31N2Dx7R013828; Wed, 22 Feb 2023 22:07:28 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=to : subject : in-reply-to : references : from : mime-version : content-type : content-id : date : message-id; s=PPS1017; bh=p2lCaK028CWliDGahcx0oHONCfOWYfW1YOg1Ki2ohl0=; b=dHZwE/c9WPijWR0ss3S075X/rFoFm4U8/WMqeK6q4LM+tv/A5zF+erZax8Uqm65ax5EO s/pUOZMuhLMMgiiU8vfuourdvE/2NTt0gRMwAh9MJtMMT/z8XiBTzaLouNp7WQssjDht zgOCzTOBxIQdB2htUzjVp2+a2YP4ujyVn8UHcwrvO3A3EqKtv5lVLHWQUTcRQSn2Dfo7 Gv6tTHEp76WRPz4m/VpwPU0eK4NYg1+0SX3RIC0ALvkeof+AQumTvUyrXfwBJxGq/ACK zo4bA7d2G7tdJFnaCIgZY4MS9jWkTWlCK0CvMY7+FGG9uY46L3tUYpU099CDfJye6sqt Mw== Received: from bl0pr02cu005-vft-obe.outbound.protection.outlook.com (mail-eastusazlp17012027.outbound.protection.outlook.com [40.93.11.27]) by mx0b-00273201.pphosted.com (PPS) with ESMTPS id 3nwy670cdf-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 22 Feb 2023 22:07:27 -0800 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=T/DoPIovWdt1BpEBFGrhMvfmqDUVI+s9HqyFa+AAuCSjhExnycZMtu9u/AZZd4UuC+XDB1DQFA93Qmw9vWAaYgSpZ/8sH0qKOyt/+aJyw2GqevMV0IGfeLF6DSzNROPwaeKl2FAMcG+x3uZiyPG848ejcCWrBfgPSfbniTj6cT/Ho8OMjFPdjh8d+Z7sK8hRC8xqHB83kXutK9pPT+llUm0TeiESsjN6ny1r/uXM5COdBNCS4aMZ7PRQPwaommZ/gioKkn326+nS7eT8291ZVOMHIeYyv1sM9RmIHJUTXYZB1v6+qL5Bh0oQiOF8xtBZmUKVW3uh2tCyQh2MbFfWeQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=p2lCaK028CWliDGahcx0oHONCfOWYfW1YOg1Ki2ohl0=; b=LLqF/apBYnSSh9bYqzoQNsap5vpdR/ukvZ/h8k0HORKZ86L94x3xmNntvDF7677o8SSCrTAh/Fp+1UPKKRJ3WBSn94WCPlcw3bmaruyvJPJ5iEPTq4FcdGdqMo9MrAqBqpZ/Svc9hVXbrn0c/k/XyGMNB0jttdt36WTRf900iwcM7StpjxV3xbkx34xfN2t4YBdpYnWctMWQn+DIWp++bwx7UzJ2R2pYbcoDV0XwWBPDGeLSVu5RnmDqLYjVdhjBMwry+iBakqyUQsPrpb0WPCMNRpw5FwlGmYaJJpBenOSj5obmu/kFFDDl5vekDd7kcijy+7M7yORrO9aaw+vklA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=softfail (sender ip is 66.129.239.14) smtp.rcpttodomain=yahoo.com smtp.mailfrom=juniper.net; dmarc=fail (p=reject sp=reject pct=100) action=oreject header.from=juniper.net; dkim=none (message not signed); arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=p2lCaK028CWliDGahcx0oHONCfOWYfW1YOg1Ki2ohl0=; b=bSxRGtMD4iMDdgJdcZ8d2YsBjj8Xc2aAwwM1MCFfzShFXtbyR908ZH8RfRIrBmRSOdZVEMU+faXOn6LW16YRgmafOBjGq5wnDm8dBUfehE9ycBljXNTbMU9PkF28vO7FYKOlSckiTKVw1pl5yB7ApyDEoQWEMlcS1zt1hw4Nhu8= Received: from MW3PR05CA0027.namprd05.prod.outlook.com (2603:10b6:303:2b::32) by MN2PR05MB7005.namprd05.prod.outlook.com (2603:10b6:208:18f::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6134.19; Thu, 23 Feb 2023 06:07:23 +0000 Received: from MW2NAM12FT040.eop-nam12.prod.protection.outlook.com (2603:10b6:303:2b:cafe::34) by MW3PR05CA0027.outlook.office365.com (2603:10b6:303:2b::32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6156.7 via Frontend Transport; Thu, 23 Feb 2023 06:07:23 +0000 X-MS-Exchange-Authentication-Results: spf=softfail (sender IP is 66.129.239.14) smtp.mailfrom=juniper.net; dkim=none (message not signed) header.d=none;dmarc=fail action=oreject header.from=juniper.net; Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.14 as permitted sender) Received: from p-exchfe-eqx-01.jnpr.net (66.129.239.14) by MW2NAM12FT040.mail.protection.outlook.com (10.13.180.228) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6134.19 via Frontend Transport; Thu, 23 Feb 2023 06:07:22 +0000 Received: from p-exchbe-eqx-02.jnpr.net (10.104.9.15) by p-exchfe-eqx-01.jnpr.net (10.104.9.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.30; Thu, 23 Feb 2023 00:07:21 -0600 Received: from p-mailhub01.juniper.net (10.104.20.6) by p-exchbe-eqx-02.jnpr.net (10.104.9.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.30 via Frontend Transport; Thu, 23 Feb 2023 00:07:21 -0600 Received: from kaos.jnpr.net (kaos.jnpr.net [172.23.255.201]) by p-mailhub01.juniper.net (8.14.4/8.11.3) with ESMTP id 31N67KYq028261; Wed, 22 Feb 2023 22:07:21 -0800 (envelope-from sjg@juniper.net) Received: by kaos.jnpr.net (Postfix, from userid 1377) id 8AAE620BCD; Wed, 22 Feb 2023 22:06:22 -0800 (PST) Received: from kaos.jnpr.net (localhost [127.0.0.1]) by kaos.jnpr.net (Postfix) with ESMTP id 8757A209F7; Wed, 22 Feb 2023 22:06:22 -0800 (PST) To: Mark Millard , Bryan Drewery , Current FreeBSD , Peter , Subject: Re: FYI: Why META_MODE rebuilds so much for building again after installworld (no source changes) In-Reply-To: <29887.1677115125@kaos.jnpr.net> References: <3345EBA5-A09C-4E3F-B94D-39F57F56BDBB@yahoo.com> <73088.1611797582@kaos.jnpr.net> <10819.1677108389@kaos.jnpr.net> <76FA98EF-6184-4D7E-A01F-0EE8117D0D10@yahoo.com> <29887.1677115125@kaos.jnpr.net> Comments: In-reply-to: "Simon J. Gerraty" message dated "Wed, 22 Feb 2023 17:18:45 -0800." From: "Simon J. Gerraty" X-Mailer: MH-E 8.6+git; nmh 1.7.1; GNU Emacs 28.1 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 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <72606.1677132382.1@kaos.jnpr.net> Date: Wed, 22 Feb 2023 22:06:22 -0800 Message-ID: <74145.1677132382@kaos.jnpr.net> X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: MW2NAM12FT040:EE_|MN2PR05MB7005:EE_ X-MS-Office365-Filtering-Correlation-Id: 2c01cee7-6d27-4007-d152-08db15643a5b X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: eASq0TiCsCQ4DPQwkdabpstnWsPp/bzlIdmIgYBTCWYZLWxpWhrW9iNVSwY/KUA7JGlXdP9uOQzzMGrdPltnPr6Z/hf3WQbQUM6DSKBW7VThS2F5Yekh2Gs/Iv/MR3hq2lJgP76vgZj8L7urI+RtDaG8L2IFhLKJnwssfTe53HaxObTY4NSnm8lUoq9bqhxP2FEiQu8JPBZM1tQ6y4A03BpD7TmnSKr6f1Divx76QJZI6wotL6ffRxQoIOXtf84z7eSKflzwbJ7Q4fCLC55K9ClVW9RstKM4BWHYnkZrUmEEf4v/AdxIr7upqYGVA404a4rsAUVn61QBH0HlTTQfsGQsbYnabW00PnTJJG4mhIvB3X5Cqy/nqqMFTbFh3M+vh6Lpp1X0npVO+z7CFXb6bqNPnH7MV7+alL0Xvb3lqQNuvjUU+NcB/hrgcUTjLj4Y0JsKVGGttP5giAlGVCaKPMHsZYulbZJcEt5BVh0nx5MbiEUHoSW0046n2zbcCyw3BVMiOVqFP5yfBLovNIVq4gNyy6Q7wBbzOmVhTgAjYEp4Sz68EWaZEO9lv2K98hY7sunSxZ8cC7FHdRJSBH2p6NEsPyHqIs4yya/PBeLYYBMHGmorGVDBadwksEPmtjIjkm4Ovcr8oGEW0lXxh21REhrV4mv0VifdMA8wsVQCXck5AhybrMJYNIGUREMX/YCb0mTnshJVEPUoBW7usB6a1JEJESXrHXUmRXk1nmprTuE= X-Forefront-Antispam-Report: CIP:66.129.239.14;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:p-exchfe-eqx-01.jnpr.net;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230025)(4636009)(396003)(39860400002)(136003)(346002)(376002)(451199018)(46966006)(40470700004)(36840700001)(110136005)(82310400005)(316002)(41300700001)(5660300002)(26005)(86362001)(356005)(4744005)(8936002)(478600001)(7696005)(70586007)(70206006)(8676002)(40460700003)(336012)(2906002)(82740400003)(36860700001)(81166007)(40480700001)(6266002)(9686003)(55016003)(186003)(7126003)(47076005)(36900700001);DIR:OUT;SFP:1102; X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Feb 2023 06:07:22.2597 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 2c01cee7-6d27-4007-d152-08db15643a5b X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4;Ip=[66.129.239.14];Helo=[p-exchfe-eqx-01.jnpr.net] X-MS-Exchange-CrossTenant-AuthSource: MW2NAM12FT040.eop-nam12.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR05MB7005 X-Proofpoint-GUID: rIUhNGXpIPzR_3In7amNs_iFtfMOsjh8 X-Proofpoint-ORIG-GUID: rIUhNGXpIPzR_3In7amNs_iFtfMOsjh8 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.219,Aquarius:18.0.930,Hydra:6.0.562,FMLib:17.11.170.22 definitions=2023-02-23_02,2023-02-22_02,2023-02-09_01 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 clxscore=1015 priorityscore=1501 lowpriorityscore=0 mlxlogscore=999 malwarescore=0 impostorscore=0 spamscore=0 suspectscore=0 mlxscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2212070000 definitions=main-2302230051 X-Rspamd-Queue-Id: 4PMjHV1J1vz3BwB X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:22843, ipnet:67.231.152.0/24, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N Simon J. Gerraty wrote: > > > strings `which bmake` | grep META.IGNORE > > > .MAKE.META.IGNORE_PATHS > > > .MAKE.META.IGNORE_PATTERNS > > > ${.MAKE.META.IGNORE_PATHS:O:u:tA} > > > > The -dM output's "is newer than the target" lines > > show the path from before the above transformation. > > (The :tA results possibly could use another > > sort/uniq sequence for the realpath results?) > > That indicates the above IGNOREs are not working. FWIW I just committed some unit-tests for these. All working as expected. From nobody Thu Feb 23 06:23:49 2023 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 4PMjgZ0RpRz3t3Y1 for ; Thu, 23 Feb 2023 06:25:14 +0000 (UTC) (envelope-from sjg@juniper.net) Received: from mx0b-00273201.pphosted.com (mx0b-00273201.pphosted.com [67.231.152.164]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.pphosted.com", Issuer "Thawte RSA CA 2018" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4PMjgY72Wtz3FJ3; Thu, 23 Feb 2023 06:25:13 +0000 (UTC) (envelope-from sjg@juniper.net) Authentication-Results: mx1.freebsd.org; none Received: from pps.filterd (m0108162.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 31N2IAIU013938; Wed, 22 Feb 2023 22:24:54 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=to : cc : subject : in-reply-to : references : from : mime-version : content-type : content-id : date : message-id; s=PPS1017; bh=SKwfTvPs8ayXXrCQSlpsuAuMLMGu5loIWIwvgUjhnYI=; b=10+uQCjG8LeKfvg1O7iu512RmRv0xwtCks0Qrx4zLkqDflmLmrXt1uVvOecdc0toOGml F0jDYt0x8DVL93Z7Sby7/PEunWTnXql4hw0ZnFMYfI0HfBIbSZTBzb/4JKFN6Idv/M1/ Qd4xR/kkcPy08JdcOdXecJgI/OSRwQh46wmz0GGenm0SUtXjj05bBeDb4lOZKbq4P3PY S5e4Ll/sMG9XMSGIodyB6IWHf+a8pRL6lc7aBZbHs0sfcV9Q1ljDG4IZTbrcT4DNK2oG 45vOGAFGh2G6tHWCplVhD+mdUSlhTTpu/Sz37AvtynlYS33dlJx99YCtpJ+i+2oKFxT+ nQ== Received: from dm4pr02cu001-vft-obe.outbound.protection.outlook.com (mail-centralusazlp17012026.outbound.protection.outlook.com [40.93.13.26]) by mx0b-00273201.pphosted.com (PPS) with ESMTPS id 3nwy858dc9-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 22 Feb 2023 22:24:53 -0800 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=GfHo2J/fVbqlyH8zYLpsT7nx0ew0ckBxObCe99mV8KHI+mFGXiFNl2noYemeNIbsPLdCamoJkPI2zxLx4LOsanLeJXV2IGuoFgh9PvLWQlrt9oEc7GLSfx2ieRYNXk9tWcVsC61EBWno2dQx+Ce7N0yatP3j168OrfgcGYysgKg2K0aU04XeKDhu8QYjfQ+XzNY7rrVSy7/jZuFkb4Ud8KYD1Cm2vMd91jnKDHUR+bfkONbPI/3M242tFIxuvGUKD7xPVnTtnQWMYNvl+yIBMDHn3ywaVmG2EyvTyBNQ6aq06lL+oxr08hLqbiRvhPUssqQ9xNg5NJPo4A6mka0qvA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=SKwfTvPs8ayXXrCQSlpsuAuMLMGu5loIWIwvgUjhnYI=; b=NiifrTEkut8zyrJsWScZhC0JxB8GfNei/hchxgemY0qDkGQu8OZFwuNfwJDsKll5f8w6yUb7eonTWpPXav6PEhdZnXddGPj3H54Txlc8UohcOddmaaK4vhtFf0OD0zGwySTVqgfGBkjVMdEHVny6IUGQ/cdvpEH41FEoNj/ICBdSX0QF79HknuVu8CrPlQOVkLLhBuKKW4CQ2jJ4F3a2S28vPEcJeElzc8SMyfxqQuw1B6+H8NQpoVndvGZothhRZ7V6DGO51ZSmguJ39YNGDlHvaN6cCA2aQTcU2VAQlamNYulJkx+fK0xjGLmZ+itkY/ZuU6i5iNh/B/RtFyoyDw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=softfail (sender ip is 66.129.239.15) smtp.rcpttodomain=yahoo.com smtp.mailfrom=juniper.net; dmarc=fail (p=reject sp=reject pct=100) action=oreject header.from=juniper.net; dkim=none (message not signed); arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=SKwfTvPs8ayXXrCQSlpsuAuMLMGu5loIWIwvgUjhnYI=; b=VOIdefVNxauHzb3s+CcLbA1sRBoqadLAKNdwR/7hLXap6rfDKysRAryVYvxTvVaJosHUI518K5Vh4AxMASzusIg48sJi7Cf1PK0HnHKJO67Rp+zbRrkunsj+VtW4htrsF3mztDC0DB/Z6HL/oSHhQJGTtYep2pCA45okSRN/wbQ= Received: from MW4PR03CA0316.namprd03.prod.outlook.com (2603:10b6:303:dd::21) by SA0PR05MB7226.namprd05.prod.outlook.com (2603:10b6:806:c1::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6134.19; Thu, 23 Feb 2023 06:24:49 +0000 Received: from MW2NAM12FT102.eop-nam12.prod.protection.outlook.com (2603:10b6:303:dd:cafe::7) by MW4PR03CA0316.outlook.office365.com (2603:10b6:303:dd::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6134.21 via Frontend Transport; Thu, 23 Feb 2023 06:24:49 +0000 X-MS-Exchange-Authentication-Results: spf=softfail (sender IP is 66.129.239.15) smtp.mailfrom=juniper.net; dkim=none (message not signed) header.d=none;dmarc=fail action=oreject header.from=juniper.net; Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.15 as permitted sender) Received: from p-exchfe-eqx-02.jnpr.net (66.129.239.15) by MW2NAM12FT102.mail.protection.outlook.com (10.13.181.221) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6134.19 via Frontend Transport; Thu, 23 Feb 2023 06:24:49 +0000 Received: from p-exchbe-eqx-02.jnpr.net (10.104.9.15) by p-exchfe-eqx-02.jnpr.net (10.104.9.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.30; Thu, 23 Feb 2023 00:24:48 -0600 Received: from p-exchbe-eqx-01.jnpr.net (10.104.9.14) by p-exchbe-eqx-02.jnpr.net (10.104.9.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.30; Thu, 23 Feb 2023 00:24:48 -0600 Received: from p-mailhub01.juniper.net (10.104.20.6) by p-exchbe-eqx-01.jnpr.net (10.104.9.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.30 via Frontend Transport; Thu, 23 Feb 2023 00:24:48 -0600 Received: from kaos.jnpr.net (kaos.jnpr.net [172.23.255.201]) by p-mailhub01.juniper.net (8.14.4/8.11.3) with ESMTP id 31N6OmMN001280; Wed, 22 Feb 2023 22:24:48 -0800 (envelope-from sjg@juniper.net) Received: by kaos.jnpr.net (Postfix, from userid 1377) id D98CA20C35; Wed, 22 Feb 2023 22:23:49 -0800 (PST) Received: from kaos.jnpr.net (localhost [127.0.0.1]) by kaos.jnpr.net (Postfix) with ESMTP id D84C2209FB; Wed, 22 Feb 2023 22:23:49 -0800 (PST) To: Mark Millard CC: Bryan Drewery , Current FreeBSD , Peter , Subject: Re: FYI: Why META_MODE rebuilds so much for building again after installworld (no source changes) In-Reply-To: <27790339-240F-4C97-97C7-38AFD8DE03D5@yahoo.com> References: <3345EBA5-A09C-4E3F-B94D-39F57F56BDBB@yahoo.com> <73088.1611797582@kaos.jnpr.net> <10819.1677108389@kaos.jnpr.net> <76FA98EF-6184-4D7E-A01F-0EE8117D0D10@yahoo.com> <29887.1677115125@kaos.jnpr.net> <27790339-240F-4C97-97C7-38AFD8DE03D5@yahoo.com> Comments: In-reply-to: Mark Millard message dated "Wed, 22 Feb 2023 19:47:41 -0800." From: "Simon J. Gerraty" X-Mailer: MH-E 8.6+git; nmh 1.7.1; GNU Emacs 28.1 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 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <67738.1677133429.1@kaos.jnpr.net> Date: Wed, 22 Feb 2023 22:23:49 -0800 Message-ID: <72419.1677133429@kaos.jnpr.net> X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: MW2NAM12FT102:EE_|SA0PR05MB7226:EE_ X-MS-Office365-Filtering-Correlation-Id: 5527e35e-e383-45dc-d614-08db1566aa6a X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: HQ9RSDQ8hTJv9v7Nf3qmB8LLWZDCkFvH08xcupj3RADXWReeyALg3i3XCD9wpo4dZuKkdZj1MzPlJaXAB0BnupEYONTL9vrXJrY8E6QBwnZN+TgFiWqlJk+uVO+dW6pvHaOioXQgVwxnTPEK+KChG/MSGotVTfNN4nG/02ybm25trj27UgQw/qWr6sN/1s1oSFAYODl4T3i6VI79H502XRU+5C94BRz/fBL577hg7Q6A5SQb4JFmLuBlvBlFJrdJC09w3UWhDYdSxP5jq+kqcVlzmnYPb7dQnFbukkGarqKq5P3L5ko0UpiVqFqtoysRfIOXZusxCtXV7kI0oHTVWPcw8662DQ+a0OSRLJVC+bIWmzQDrgx1nRmynHftX3cgnA4H6+8AuXRhnNXi93om5zKW5oDz4AETakk0tJYRYXc0rj5UcSV2je5OiIRmJwS2WuKt+HxNpFvqSm8AWJvSwjAjUXwP1+QIR5g0zAPRABoIsxXzrjQRjOsOU/310EBi3F5r1M68hPR3OWni8DXqLxP1CXENDNDZz9veTf0YA3ydL4QB823TLYs0FF9EIfe3Wc3raBbHW+GgQVMAalGbmU8KnA+FVs+ebR2/C0uVHd+fEp15e9o2JbMhE7YZ/arBCr8oNXJpmeqp4ThRMF07uR3CYuIntXDHE2UoTOxvU81IyUabWBnW0oG8aVN5/NJ/U5x+uWyptyvfGQinGpNcM4sc8280ZOE25tztlzFHFNlVygKxvaY1wZRTV6MRA5vUcFgEJaweXjHBFG4mRq1Ry/HTY2gTEdXsfOzB7U/JjhY= X-Forefront-Antispam-Report: CIP:66.129.239.15;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:p-exchfe-eqx-02.jnpr.net;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230025)(4636009)(396003)(136003)(39860400002)(346002)(376002)(451199018)(46966006)(36840700001)(40470700004)(186003)(107886003)(6266002)(26005)(9686003)(7126003)(336012)(478600001)(54906003)(7696005)(47076005)(316002)(83380400001)(82740400003)(6916009)(70586007)(70206006)(4326008)(5660300002)(41300700001)(8676002)(8936002)(36860700001)(2906002)(81166007)(40460700003)(356005)(40480700001)(55016003)(82310400005)(86362001)(36900700001);DIR:OUT;SFP:1102; X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Feb 2023 06:24:49.2564 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 5527e35e-e383-45dc-d614-08db1566aa6a X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4;Ip=[66.129.239.15];Helo=[p-exchfe-eqx-02.jnpr.net] X-MS-Exchange-CrossTenant-AuthSource: MW2NAM12FT102.eop-nam12.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA0PR05MB7226 X-Proofpoint-ORIG-GUID: 1q2qcWI8XMwuYVoctk3SsxOb1fxcAr96 X-Proofpoint-GUID: 1q2qcWI8XMwuYVoctk3SsxOb1fxcAr96 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.219,Aquarius:18.0.930,Hydra:6.0.562,FMLib:17.11.170.22 definitions=2023-02-23_02,2023-02-22_02,2023-02-09_01 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 clxscore=1015 impostorscore=0 mlxscore=0 suspectscore=0 malwarescore=0 spamscore=0 bulkscore=0 priorityscore=1501 lowpriorityscore=0 phishscore=0 adultscore=0 mlxlogscore=999 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2212070000 definitions=main-2302230054 X-Rspamd-Queue-Id: 4PMjgY72Wtz3FJ3 X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:22843, ipnet:67.231.152.0/24, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N Mark Millard wrote: > > > > Is there anything under ${OBJTOP}/tmp that you don't want to ignore? > > More than just _bootstrap_tools_links entries end up in > ${WORLDTMP}/legacy/bin/ (so in ${WORLDTMP}/legacy/sbin/ > via the symbolic link pointing to ${WORLDTMP}/legacy/bin/ ). > So: yes. > > Also, OBJTOP is not constant over all the parts of > buildworld buildkernel . Having the late-substitution > form of notation ${OBJTOP} might not be appropriate > for the content of .MAKE.META.IGNORE_PATHS . Fwiw .MAKE.META.IGNORE_PATHS is evaluated when meta_init() is called after all the makefiles have been read - and had a chance to influence .MAKE.MODE, so I'm not sure how varaiablity of OBJTOP would matter? > > .MAKE.META.IGNORE_PATHS+= ${OBJTOP}/tmp/ > > (Ignoring the variability of OBJTOP issue . . .) > > I do not expect that would work: ignoring things > it likely should not. Sure, but it may be useful as an experiment to ensure things are behaving as expected. > Also, I'd rather grow a smaller set of ignores > gradually to make it easier to detect if an > addition starts causing a problem and can be > backed out. Starting with everything ignored > would make things much harder to figure out > when ignoring creates a problem. Yes. > > > You might need ${OBJTOP:tA}/tmp/ > > or both. I found it necessary in the unit tests to add :tA to both TMPDIR and .OBJDIR to get sane result on one test platform. > >> It is using paths that match the -dM output lines ( sbin > >> use despite sbin -> ../bin being a symbolic link). use :tA if you want to ensure consistent results. > > I really need to add some unit-tests for these... Done - not yet imported to FreeBSD though > You may want to wait while I see if I can come up with > a better example context to show things. I only just > noticed the late-substitution potential issue and > started looking for a way to avoid it, for example. > (Either a value that does not vary or a form of > causing up-front substitutions in my make.conf .) Ok From nobody Thu Feb 23 06:43:26 2023 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 4PMk6C0WTHz3t4j3 for ; Thu, 23 Feb 2023 06:44:51 +0000 (UTC) (envelope-from sjg@juniper.net) Received: from mx0b-00273201.pphosted.com (mx0b-00273201.pphosted.com [67.231.152.164]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.pphosted.com", Issuer "Thawte RSA CA 2018" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4PMk6B6lb5z3JWh; Thu, 23 Feb 2023 06:44:50 +0000 (UTC) (envelope-from sjg@juniper.net) Authentication-Results: mx1.freebsd.org; none Received: from pps.filterd (m0108160.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 31N2DwYt013821; Wed, 22 Feb 2023 22:44:30 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=to : cc : subject : in-reply-to : references : from : mime-version : content-type : content-id : date : message-id; s=PPS1017; bh=VJ67J/AvFDYg/or1wGOu0EUqxCC0sokeF7j7L71BP3k=; b=TUzmmZtyH6ePmwVuFgRDqFirCct16MXh7+it/pdcGr1OlVubVTqRXHngwiRq2wnptgnq FMZWy7+Eh7s82WnpF5Tb29lOH4Te50xDz1Y43nbmuYnFEGdsEb53jIvE1gz+QWxGVZ8q zgoSZ8OIC7FThIskz2E0Et6mHzXlxUWQopNxkVMPniNok7hAdC2HnW3K1Hb/+aZ/Jlbc Nlw5yiLDSMIWI3yMCnXAOPx5bj3xmWcGh8ldIXWBKL3B/LXDmafDO7MeBg78oleTfNXU erUQE7ks0JsTdb7tQmsUPnXZx3ERWcmnJFk/QxBB3g3xRSkmjH35jhgFYBKMWdv4RuYK 0A== Received: from co1pr02cu002-vft-obe.outbound.protection.outlook.com (mail-westus2azlp17010005.outbound.protection.outlook.com [40.93.10.5]) by mx0b-00273201.pphosted.com (PPS) with ESMTPS id 3nwy670ehx-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 22 Feb 2023 22:44:30 -0800 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=a6gWTWYsuOh6oapcFHCzx7hNo1TTsmHLPJ7ySApauC56mkumfscE3rj82xF8F6lGVnFz+RFzygIFykQob7RwgqH6N2xgGwXFnmngNO05g43jMIUH8/VVwpLHYdc7Y7XIULUJmkSyxO5yJ3GgjgEyhlhnTfBFu8TQIzqRa7HZW7b7bpvR50jhbh3gVVBb6Xt9nCUESSwLXHkupCk7s2gpwksBtF6ikeKYEuohY0bdJDBoRkXFmB1AKBklDZQNBcDJHjmQHzpRz+IlnQH8Vq+ARq58BZqwp8aXKSjC/jFiS/9S2WUy6r51br5M1Ma4Btw3GhmSAuq/6V+KQBOk0r/dJA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=VJ67J/AvFDYg/or1wGOu0EUqxCC0sokeF7j7L71BP3k=; b=ko/GifXTqxYy5qyvRXBPvmPNm5EXoqhAZnGdRhvyQ5dwbnhaejsePBHbHPVGxE9uKigeFnHV1vJ/Se17hTm+eXwCh+9p7mT5et6As15+nyFQIy7XYkTrRfbkYvEe+FlF2lB0KHXMOBcjdxJQVAhAXyMSv95zEDhQYDyXnAIKb5UsyPj3jNLAA6rZcs34YQDHafspQk3oGCRw7xhzWNm2wshz0CeE/hRMofdm6JtH3DYb9pbWZbq7DN/tNOoesL5J9M0EGW9w3Ras5E5Ubz1TWHIvJwFrjcKXUWzgNtcPvzxRciNaQbkMz5rfrS0hiNHkUs92RfLfmJ3M0dakVV1tFQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=softfail (sender ip is 66.129.239.15) smtp.rcpttodomain=yahoo.com smtp.mailfrom=juniper.net; dmarc=fail (p=reject sp=reject pct=100) action=oreject header.from=juniper.net; dkim=none (message not signed); arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=VJ67J/AvFDYg/or1wGOu0EUqxCC0sokeF7j7L71BP3k=; b=cXMuzIjC2zH64Rq6ZRBYt9G5PqjB2U9Nf3s1sYrGM21GMVLcTppRalefTyDUnoNy4QP7BZAGE5ye++IRV+j4PwKxx1VS6c+oLme0LpFUP1ldr0H5Tb8wVR3ZNBG43PuCnQ1UPui+DxGkGdd7WIx4+OsJi/e5a3RxB2bTP1+EUwQ= Received: from DM6PR01CA0011.prod.exchangelabs.com (2603:10b6:5:296::16) by CY8PR05MB9819.namprd05.prod.outlook.com (2603:10b6:930:74::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6134.19; Thu, 23 Feb 2023 06:44:27 +0000 Received: from DM6NAM12FT097.eop-nam12.prod.protection.outlook.com (2603:10b6:5:296:cafe::ef) by DM6PR01CA0011.outlook.office365.com (2603:10b6:5:296::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6134.20 via Frontend Transport; Thu, 23 Feb 2023 06:44:27 +0000 X-MS-Exchange-Authentication-Results: spf=softfail (sender IP is 66.129.239.15) smtp.mailfrom=juniper.net; dkim=none (message not signed) header.d=none;dmarc=fail action=oreject header.from=juniper.net; Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.15 as permitted sender) Received: from p-exchfe-eqx-02.jnpr.net (66.129.239.15) by DM6NAM12FT097.mail.protection.outlook.com (10.13.179.107) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6156.3 via Frontend Transport; Thu, 23 Feb 2023 06:44:26 +0000 Received: from p-exchbe-eqx-02.jnpr.net (10.104.9.15) by p-exchfe-eqx-02.jnpr.net (10.104.9.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.30; Thu, 23 Feb 2023 00:44:26 -0600 Received: from p-exchbe-eqx-01.jnpr.net (10.104.9.14) by p-exchbe-eqx-02.jnpr.net (10.104.9.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.30; Thu, 23 Feb 2023 00:44:25 -0600 Received: from p-mailhub01.juniper.net (10.104.20.6) by p-exchbe-eqx-01.jnpr.net (10.104.9.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.30 via Frontend Transport; Thu, 23 Feb 2023 00:44:25 -0600 Received: from kaos.jnpr.net (kaos.jnpr.net [172.23.255.201]) by p-mailhub01.juniper.net (8.14.4/8.11.3) with ESMTP id 31N6iOHK007334; Wed, 22 Feb 2023 22:44:25 -0800 (envelope-from sjg@juniper.net) Received: by kaos.jnpr.net (Postfix, from userid 1377) id 5D8FE20D24; Wed, 22 Feb 2023 22:43:26 -0800 (PST) Received: from kaos.jnpr.net (localhost [127.0.0.1]) by kaos.jnpr.net (Postfix) with ESMTP id 5CBFD20B52; Wed, 22 Feb 2023 22:43:26 -0800 (PST) To: Mark Millard CC: Bryan Drewery , Current FreeBSD , Peter , Subject: Re: FYI: Why META_MODE rebuilds so much for building again after installworld (no source changes) In-Reply-To: <7FB6F619-6E71-4075-8A6C-573564371DD5@yahoo.com> References: <3345EBA5-A09C-4E3F-B94D-39F57F56BDBB@yahoo.com> <73088.1611797582@kaos.jnpr.net> <10819.1677108389@kaos.jnpr.net> <76FA98EF-6184-4D7E-A01F-0EE8117D0D10@yahoo.com> <29887.1677115125@kaos.jnpr.net> <27790339-240F-4C97-97C7-38AFD8DE03D5@yahoo.com> <7FB6F619-6E71-4075-8A6C-573564371DD5@yahoo.com> Comments: In-reply-to: Mark Millard message dated "Wed, 22 Feb 2023 21:09:54 -0800." From: "Simon J. Gerraty" X-Mailer: MH-E 8.6+git; nmh 1.7.1; GNU Emacs 28.1 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 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <30.1677134606.1@kaos.jnpr.net> Date: Wed, 22 Feb 2023 22:43:26 -0800 Message-ID: <2655.1677134606@kaos.jnpr.net> X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: DM6NAM12FT097:EE_|CY8PR05MB9819:EE_ X-MS-Office365-Filtering-Correlation-Id: 10b7c84a-9233-4962-30f5-08db15696827 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: 16AGz6JkXNsBiJ+dnY98wUDevjw0otIswAOsnm0ZayRWX9YbF8FG+SKPFuRNspety8jHLkmpwztxs46wbKaS6YafV9MTlbxs/MxI1vcGhriOHyZvFidB+qDpsD7MZuOu6MO2Cqtevw6XiLmMh/qAew+t1Dah8BYjmA7G8fRcBPEUODuM0mH10TgqpvnW0eSomUm/rXxznkHz61yAYZ0QAync31MePcZlwZPaqhLpipsm3fY+/2+sVtr9LS0caC1f5+LCi50rmgvVJVggIVp5PHEGmb7QOOI1UOplEbeiiIoIH0y69vmSL845EeVlE8GnXk1QdfSqwQWA+NDNPD42HAuQ5E1jtMhYltc2SuIvePIlybppKqFhnc470OsWC6NIS03wRuZ7+riCjFABDSQJ2m04g24mBI3Kn0YHhtNI38mCdujRG5bT8Dido3BvLeOB0uCV7qwLVbCIRBimbzqZBoRZKDDnw+3ox7Xc2q2MYh33aFw/c594mKt2sxjty86wi/VKc6KYC4xCv9noxmdIzp+Og7n4bGtpoUPARMWudum3J6NYON5O5etrnVMnT/EOjmnx7oq/nmT1qpLh/zf8RT/aF9IUvoCKyXhTghfCm9u07Q3Jc37kcOVH8QvLJBxz5hsnfdKytjOeYRn/NV00T49lnGU8KNaWirjDes7UUDvkheNjEt5wWJPBRS8VHzjKFnZtKJZOeI1IKP8c0/yFVRLfNbHhYBsE6PXBoEfnl64= X-Forefront-Antispam-Report: CIP:66.129.239.15;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:p-exchfe-eqx-02.jnpr.net;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230025)(4636009)(376002)(136003)(39860400002)(346002)(396003)(451199018)(36840700001)(40470700004)(46966006)(186003)(7696005)(26005)(36860700001)(5660300002)(7126003)(6266002)(336012)(107886003)(9686003)(478600001)(54906003)(47076005)(316002)(356005)(41300700001)(8676002)(40460700003)(6916009)(4326008)(8936002)(55016003)(40480700001)(70586007)(70206006)(81166007)(4744005)(86362001)(82310400005)(82740400003)(2906002)(36900700001);DIR:OUT;SFP:1102; X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Feb 2023 06:44:26.5267 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 10b7c84a-9233-4962-30f5-08db15696827 X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4;Ip=[66.129.239.15];Helo=[p-exchfe-eqx-02.jnpr.net] X-MS-Exchange-CrossTenant-AuthSource: DM6NAM12FT097.eop-nam12.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY8PR05MB9819 X-Proofpoint-GUID: HvFzC21hcT_4oyvyF3qtrhx5wS2qFalf X-Proofpoint-ORIG-GUID: HvFzC21hcT_4oyvyF3qtrhx5wS2qFalf X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.219,Aquarius:18.0.930,Hydra:6.0.562,FMLib:17.11.170.22 definitions=2023-02-23_02,2023-02-22_02,2023-02-09_01 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 clxscore=1015 priorityscore=1501 lowpriorityscore=0 mlxlogscore=436 malwarescore=0 impostorscore=0 spamscore=0 suspectscore=0 mlxscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2212070000 definitions=main-2302230056 X-Rspamd-Queue-Id: 4PMk6B6lb5z3JWh X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:22843, ipnet:67.231.152.0/24, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N Mark Millard wrote: > It appears that for symbolic links being the target, META_MODE does > not respect .MAKE.META.IGNORE_PATHS . The handling of links is rather complicated ;-) Among other things, the src needs to be treated as for a Read and the target as for Write Note that .MAKE.META.IGNORE_PATHS is only applied to absolute paths .MAKE.META.IGNORE_PATTERNS and .MAKE.META.IGNORE_FILTER can be used to apply more generally. --sjg From nobody Thu Feb 23 07:10:49 2023 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 4PMkhT3w3wz3t6GK for ; Thu, 23 Feb 2023 07:11:05 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic303-23.consmr.mail.gq1.yahoo.com (sonic303-23.consmr.mail.gq1.yahoo.com [98.137.64.204]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4PMkhT1bZmz3Lw4 for ; Thu, 23 Feb 2023 07:11:05 +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=1677136263; bh=xJNIS6YmM47VglZVZkX334UdaiS+TUVagCkkdtkZp/c=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=L/ktoHmq4FDu1pK1vCfDxNL4TjacbcFY8yLNstTWSNtT5Ko2H6br50UHUygubvjPA4dlGvXU4ubJAPZ8LDwPBshqO9r7AqHzmi8jALY5D2g/8uP1iIEojOlAmBgyg8/YpB10kGz5K9AGzPpEILTa+ZBUGGA1LFktm32aCe7VGePtYbh9SXvJ2kFLNbYFlatlbH23ZxkS+a1nQ0eV9gttr9gBKmG58ZuVPnRO/AQvi8ZH+EFB5XP3XpPAiJkdG/RnlLyu0gryP1JHSyXnYEkW9Te6HNSkMSxK7XLCnLCWZ5B1o8q0bgP1G66yZ9RE6q0JRN1ZY0R6tYppi97BAN4Ljg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1677136263; bh=kLjRebbbN0+GXypmDpyJQZc7rnXli1764Xa+KImOw54=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=m68O3LM8a/wSMewH1QQzCZhSfs5Cx3uELb//xdtMyhEbKzC5ai2d0Dq4OVR8TbDXIBvYOnJvKKaJXfcanMY7D3wpbe+OANMZl2dwE8NMf8RnFZtwk2GUq1X6RnPuzc/O6RrMDjdfsimpbEux6vmUNzL+dCSKvfnbqVFeJi4zzpW6s1ClBTM8mA2fpwJMhqZHcce4aq7oS6GRTTv10bihXeLvgJ4K5DusLgqx7EWfuVy6ZBrJg/iY8yVh85h8w/ANNoAObhvL8//blq4EKeIpzKWLcCctnOhMCaXoih8+1oSnplrug3iYndDILTl9RPCuJYOgOnF2lixII8OMaYZ1dA== X-YMail-OSG: gPNQ_DkVM1n3o9VqdDLhg5T_VZ1v6DMTjV43dXevtGkuUYaVtYtR1zjZB6OaDZo Fl_y_p.9p8zMqtRzypo59a5LMm_kvJWBu4ffR9NE0efOwxMvtVVo4atcuV29brdm1.qXdkgRZZjO UkQm6MZrFwgO_Svyd2P7b7IqWRtOImOKsrF9NbDbDPlhjDtxAdb6wxTuqY9MyZs1qkVpMGa2oki1 SDFojYv.7rbFqM3nR9vY0X2AFGDfgxAfyZAQ.LMkBFXLdzDE3Ek8krS_QrsHY5Byf5tJJ64jtmve lTwmqylfjK6ZOnkEKfHoDkQk8WAPshS3r6A4J4qfYIV6KXmK3xzJ8Ut2KsuTfbnERW2Q1pHkSVCO jUuimoOa6ohyaLWDuB30z7vc13o.DiEtpV0dsywfWjNONsiZDjlOtXHxDYp4C7NBE2FPB33GUG26 Zv9cWAEdpIJSochG4Df.jhIaJxcZPal.ZdoIc65.qSq7Lhl9FQ4SaN3g7ziLmK6_bWm6Sm1QQy38 DVoOO.T_GKXXLX0ugmJHzk.awqUoqF2XmNXWTVGNcTV43iYTcbsQCU8xMa_WiyusPMmCzWD4vvCK 2j54SMEtDp6fOCestTLLZ2Zy80FMTtt3yJ7SaN4atHrdGRnzP0fUAF7iSxM_tGCd36J8VjJ9r7j_ 0K.d4zKu8j3gKgXnW1OuKIr8Q3708gSuiDKYdgK6VqrJ92FUPUNu7cMZZ7T5nH5lfbdwGhDSfhLA uxvuybLF9TQOvmbXcV_8IT0_zOmGHuGks0KkeKRhpnFafKHdhtclNW7tE58J4GGqnVHqhL8_3DbK 9FNd4W6sLOjF4iz1CKvR.SVbTaHkk2Ekvcl57RRXmAfKAoStQPpHjRByfBj0cYxz.Q0Twa_4dqS6 WWeKrwhxw5s5Ho4ErMtGH9Snj_6HnHtGIBWMxb.pk8A54IQcemRkbqNJsRNpv07xgZV3HcG1fpHU hfvYQHk8rQ42VzfEUKGtx568n0OgNF1ZY2i04_V_ll_JwC4I5CzRGgzliGDQM0asvlUqLuZWZ3kc JVzzJANILs_F20utzGM726nRgJOAtcEyy16ZoawkF.d0Ilq6W8LzFNGkDq9wMAFoOBsN27HUUciJ bHYHpuYJF9GlaHJ49tzu3POZQTQRlZ0JFVyqgSfpT81N6SZuDSENa9un.mZ9byNJIkCZb54ifihb WjQ.ixNG.cu6mTpNzS1d5RwkkOLpI8KmKKxvo0OR8Xx_WZNqrNBDZ6sQjnvc_Vt7PfwpWdCx.IKH LK4R8XtLhzu4ZnTvIxeH4lS3eLPD0tZGyg7AGQT.r7_ChKFBGvY7cdK5unDUsAvtrUwgPYMtKLfZ _gl84lAzTES5VPzRbWh5QsMfdo58rSdTvcCmMsWJ_VrIN9ErgFNkSPfpvmtKBUVs5zPWOzucQyxw CiNNolJ7puIIJcCcvocloEOxJVeUBN..iWPgjzCA29lhWmDrO9y5YJv0Hyhln4U_5KrvilIJQwQR AvVdF1SkRufCen..lGKDP9nZbeRLmCiixNkR611KUjaIiC5ZLXOWlVzY3hqVv5sMEdkpIpp6Mi0U WLgEPWbckTnKOS1kg.i6_kHhr3J89QhlrzpGweFzRaBhGPpdGFsVFqtqaGbeOHGu07KIdRoC8T66 2NoAzQd1VKqmRSLaR1Al57lQYJNb9KF1KhA3icERORyujW1sCCzMW4OcZMN_RYfYqx28JN5Zgt3L PqrS53yIRWuFnRsVbjKKLq91EybTwMIK47hJdkRjzOgzmfmN2kBBfXntvN7MPZAQOmI61RuZWKsK cuF49T9d2R5ZqwuFDOTFWDCc8dK5YaobyNyEaleNN1or_yFSg9qN16L5pSyWsTYcZx4GfitOZqQy IDzNbFIfaPIJb6iyDu_ni2uuHpR44L5MAZth7FFDRB.ctLEP.uFwAbXmMR4lWGqKBxomqI0BQTaQ .kqGq5A3GmZWXnR0FDs2EyqRJudZP90dW.dLHB20ZSxn8NSzYoV4F6IZDeE4IFFvedBV7vADE_lY xJcm36AL3b4tgPH7VS09GXVVxuFC4mtbdSJgV8rymoWU2i2SXJlsvj5i3rZBCCqp56Fp4PO2GxIn 5weRuUP_l_E9wp1ULSrGGC7l1GKMlK9mwy9n6vNoaCwnUX8jxb_sLuMucRcfoBTLEvNdr9hSNzVp xfylEy0hdfJVof7oHEIfqiGaGIhIulxd_uG6cZ0fza72Hr0In1EFpaBV4p0.5vDslhVBxtsEstjy T2u4OjcUhk7ohcZ4G9m_7ESC2x.nLCg8AuxruVHRHoUUcv57pcjZOKsC_JnDAEyYyIhI8hYFJNU0 - X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic303.consmr.mail.gq1.yahoo.com with HTTP; Thu, 23 Feb 2023 07:11:03 +0000 Received: by hermes--production-gq1-655ddccc9-nql2v (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID ca47a5c26854a511913cadc9f3ba9a13; Thu, 23 Feb 2023 07:11:00 +0000 (UTC) Content-Type: text/plain; charset=us-ascii 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 Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.400.51.1.1\)) Subject: Re: FYI: Why META_MODE rebuilds so much for building again after installworld (no source changes) From: Mark Millard In-Reply-To: <2655.1677134606@kaos.jnpr.net> Date: Wed, 22 Feb 2023 23:10:49 -0800 Cc: Bryan Drewery , Current FreeBSD , Peter Content-Transfer-Encoding: quoted-printable Message-Id: <242BB478-B2FE-4BCC-A56E-098F3FEB3EE1@yahoo.com> References: <3345EBA5-A09C-4E3F-B94D-39F57F56BDBB@yahoo.com> <73088.1611797582@kaos.jnpr.net> <10819.1677108389@kaos.jnpr.net> <76FA98EF-6184-4D7E-A01F-0EE8117D0D10@yahoo.com> <29887.1677115125@kaos.jnpr.net> <27790339-240F-4C97-97C7-38AFD8DE03D5@yahoo.com> <7FB6F619-6E71-4075-8A6C-573564371DD5@yahoo.com> <2655.1677134606@kaos.jnpr.net> To: "Simon J. Gerraty" X-Mailer: Apple Mail (2.3731.400.51.1.1) X-Rspamd-Queue-Id: 4PMkhT1bZmz3Lw4 X-Spamd-Bar: ---- 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-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N On Feb 22, 2023, at 22:43, Simon J. Gerraty wrote: > Mark Millard wrote: >> It appears that for symbolic links being the target, META_MODE does >> not respect .MAKE.META.IGNORE_PATHS . >=20 > The handling of links is rather complicated ;-) > Among other things, the src needs to be treated as for a Read and the > target as for Write=20 >=20 > Note that .MAKE.META.IGNORE_PATHS is only applied to absolute paths > .MAKE.META.IGNORE_PATTERNS and .MAKE.META.IGNORE_FILTER can be used to > apply more generally. All paths that I'm adding are absolute paths. For reference (my additions are after the normal ones, I use -dV here to show what is based on other substitutions vs. not): # = ~/sys-build-scripts.amd64-host/make-main-amd64-nodbg-clang.amd64-host.sh = -dV -V.MAKE.META.IGNORE_PATHS buildworld buildkernel Script started, output file is = /usr/obj/BUILDs/main-amd64-nodbg-clang/sys-typescripts/typescript-make-amd= 64-nodbg-clang-amd64-host-2023-02-22:23:06:28 ${__MAKE_SHELL} /bin /lib /rescue /sbin /usr/bin /usr/lib = /usr/sbin /usr/share /usr/include /usr/local/etc/libmap.d = /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/tmp/legacy= /usr/sbin/awk = /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/tmp/legacy= /usr/sbin/cap_mkdb = /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/tmp/legacy= /usr/sbin/cat = /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/tmp/legacy= /usr/sbin/cp = /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/tmp/legacy= /usr/sbin/crunchgen = /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/tmp/legacy= /usr/sbin/crunchide = /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/tmp/legacy= /usr/sbin/dd = /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/tmp/legacy= /usr/sbin/egrep = /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/tmp/legacy= /usr/sbin/env = /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/tmp/legacy= /usr/sbin/file2c = /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/tmp/legacy= /usr/sbin/gencat = /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/tmp/legacy= /usr/sbin/grep = /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/tmp/legacy= /usr/sbin/gzip = /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/tmp/legacy= /usr/sbin/jot = /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/tmp/legacy= /usr/sbin/lex = /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/tmp/legacy= /usr/sbin/lb = /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/tmp/legacy= /usr/sbin/ln = /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/tmp/legacy= /usr/sbin/m4 = /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/tmp/legacy= /usr/sbin/mkcsmapper = /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/tmp/legacy= /usr/sbin/mktemp = /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/tmp/legacy= /usr/sbin/mv = /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/tmp/legacy= /usr/sbin/patch = /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/tmp/legacy= /usr/sbin/realpath = /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/tmp/legacy= /usr/sbin/rm = /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/tmp/legacy= /usr/sbin/sed = /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/tmp/legacy= /usr/sbin/sh = /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/tmp/legacy= /usr/sbin/touch = /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/tmp/legacy= /usr/sbin/truncate = /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/tmp/legacy= /usr/sbin/uudecode = /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/tmp/legacy= /usr/sbin/uuencode = /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/tmp/legacy= /usr/sbin/xargs = /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/tmp/usr/bi= n/ctfconvert = /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/tmp/usr/bi= n/objcopy = /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/tmp/usr/bi= n/nm Script done, output file is = /usr/obj/BUILDs/main-amd64-nodbg-clang/sys-typescripts/typescript-make-amd= 64-nodbg-clang-amd64-host-2023-02-22:23:06:28 The contribution to the list is currently generated via use of: .if ${.MAKE.LEVEL} =3D=3D 0 .for ignore_legacy_tool in awk cap_mkdb cat cp crunchgen crunchide dd = egrep env file2c gencat grep gzip jot lex lb ln m4 mkcsmapper mktemp mv = patch realpath rm sed sh touch truncate uudecode uuencode xargs .MAKE.META.IGNORE_PATHS+=3D = ${MAKEOBJDIR}/tmp/legacy/usr/sbin/${ignore_legacy_tool} .endfor .for ignore_other_tool in ctfconvert objcopy nm .MAKE.META.IGNORE_PATHS+=3D = ${MAKEOBJDIR}/tmp/usr/bin/${ignore_other_tool} .endfor .MAKE.META.IGNORE_PATHS:=3D ${.MAKE.META.IGNORE_PATHS} .endif The :=3D use is how I avoided needing to worry about late binding substitutions for my additions (independent of the internals of make's specific .MAKE.META.IGNORE_PATHS handling). For reference: # more = ~/sys-build-scripts.amd64-host/make-main-amd64-nodbg-clang.amd64-host.sh kldload -n filemon && \ cd /usr/main-src/ && \ mkdir -p /usr/obj/BUILDs/main-amd64-nodbg-clang/sys-typescripts/ && \ script = /usr/obj/BUILDs/main-amd64-nodbg-clang/sys-typescripts/typescript-make-amd= 64-nodbg-clang-amd64-host-$(date +%Y-%m-%d:%H:%M:%S) \ env __MAKE_CONF=3D"/usr/home/root/src.configs/make.conf" = SRCCONF=3D"/dev/null" = SRC_ENV_CONF=3D"/usr/home/root/src.configs/src.conf.amd64-nodbg-clang.amd6= 4-host" \ WITH_META_MODE=3Dyes \ MAKEOBJDIRPREFIX=3D"/usr/obj/BUILDs/main-amd64-nodbg-clang" \ make $* =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Thu Feb 23 08:07:54 2023 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 4PMlyM2Pmcz3t9TL for ; Thu, 23 Feb 2023 08:08:11 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic316-8.consmr.mail.gq1.yahoo.com (sonic316-8.consmr.mail.gq1.yahoo.com [98.137.69.32]) (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 4PMlyM05T4z3hqd for ; Thu, 23 Feb 2023 08:08: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=1677139689; bh=9jFrbPud81hCDzVJ77XufiJMwiUKk/O7NzXzDhRyn7s=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=PlKVpZXuTuVRisaG2GhqoJHUf8wPpi6SARgHZWfJR4XMaQSPCK0+iChxb4mRNNDT+vs0nCH3okmEyhT91IjrGanxuF2T32D2ZVI26wx9foN6j2aab0RGQN7Wxlx+BJ24eBznm8yukrEr5Up7X9JOD2Fj/41Br6GrkpHYAnoqinKlDiTkixwNxNee3AP29qitFy3Qft3OlX6cJ6cLYkhKC2WOoWBVk9W8NIAtx13LHokUyrMIRZiqEl20ojrJIpyKBn/NoUh24dnsMKLjTd5VTtTFgz7Dj2Ew/rYiiYVwhBdJjYp9fHkkqMPDr0mQ/8rxB1U8fForXci3/d8AHJom9A== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1677139689; bh=7pfvO5bhJrz7cd1CGwbrVj85bfXo7Zt8WSGyEjXZeFG=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=fx5zAd14qCYflQWVLSXGKN400PSXqonxA0/74pw788zb2lNRhEKlsMrNonAu2Y1cLljTscNjFRPwXZzAQ/FYQyE3OFDvsCl9NAbt+CynCAfy4EX5HfDYxM+BvaI+qSNtEmi/Ijd+KMXw4OsrrvazqdZ5Ts31KC4y/wGhuMx+wQ1EW/oT3WkwvCfUU/IIiN6gv9DZJAaA3owY+IOH4ErMi9S+A3v+nYOZtpXj2cNC09DuJaMv08WEqTAHo7XQe4AKYdVAxktnICamZT+NvfotZC5Z0ho35BeN1lUSyluP5Hv9nKMgZAgmfc0i6MkNZWF+5Cec+D9ky63+JwbQiKBVSw== X-YMail-OSG: m63VOaoVM1mA7c3Jv3jgu6I0Pmi_X5OCoJ4oJsEZsxNzpd.gT1hr9SyfkYlrceu OAdPQJLdLA3QMH1KJ8xKle92yl2pG2nDu7qeDhVeSdwbYHnGa6P5H3iereZCj0EVnuo5vF0y.CC0 DL4Ji8telxa4Jw6zDZn5UW69oMfClflOoBqv_XcNVj6rHjMe6RpuTM15gfjMxz5PXaDCTxn6J7En 4bKbKur6KVS5Y1j6OfwHqT0FqCcoIBH_jf.Co.TSu_wFsYYfR._ei8qPs1ub8RVRASlHCpeOIuGD sxXUyug3FrPv8FwbjqyVIZgQacTBJLAEAmTWJesJvbc7k7rAscA1a7xnh6K.eIK6i34Z0sAd6s1k ateW4tZlCUaDzfmD8k0Q5626gJzHXYEWMHf003p3snPFLrc_f.WPHM4t1GjAHaQBKTY4NJGI4QRy HoMCv9Vxg6BRiNzHUuyboGuiRipvRIr3qFLtje4Ee7K_0My.eSr0tOwv2AGKqliAmpHnFN7wPRmn gZAJoCWLmTs86BaH4pubTU2lUGHN9D5w5_37GOpWhzOPrsm81RX5l44FdymsFdGZt6yy1CV9crhn NkYoqW0QcPTMa_MVXzHZMdwN0IcbiDf8q3vpUgf0jyF3w9p5NIksdOFdFxi.4QjmM4kOUXq173Xf nvXfGBrvpFwfFhs41VEnlQG.4KsAw84ykm0P1hgAvP_InVD7wJK59sU0nZCSeS.9AIieYIhKFX8K DI0Foy1iqtuu2VJZeItF8jwp0sV1wroFn2Ig26wfcI7wL0YXCDsr7.to4x6f1_A78CwiWhQ31UX0 QKVVfGs8uodCSldFiE0ctj25xVpQLbHKTn3x09stxEngs8l5do9eau0R5uWM1rvoAESoVEUr2RFw DwHo66hBXKPo5V1K44ywyCUUW2hOwZNkkd1HNlBJ.F7PwjPAzWtnkwOSnHBwb5EluaB6deBu0Fnl _qGFuPSwIbQOLARMmMCAnDeXrym9aSHwOCtmW_pA7l53wWInVXQ_du2zaclUVKn16IPgsZTzOin2 9pHZrKt_ev5BIxWq9WHe.fkYlNg18b5S.0BxPzXUtLWuEYcm6_0th12LQ78gDajr6ud_SyK7noF6 VosADKNRBTYj0t8OMizR_R4sHZUGiNFBUY.5WaZQfDyQXjvcMw8oBIN_yBkETn.2.dN2SQv04bhl LDI.OlwA_H.FYA8yzdojzQBjOGI4g8sCphCX0d0cRmhaIWRD9QZxXgIFWy6otIQpXnPoHGAxLkYH H6lqIJKtne6umfBU1sIZLXTR17yRFjpiNtOZVvN4xcPUfmPOADKA7KCPiw7Kc7dmNd7mx9SmdmeX fx80E_mmrYmqh595G6k0hBWWsiAKiQn3ArCrZwqGBrfYvooOhR4T5aOPnF9c4oQwUiIBh5vCxOKo DweZLT50dzoO5YVrXTaI0tPkH3CmaIfSNVGaU2PZjk_9RU5jDJhtOVPU9S9MOaqLRp_g0y2fMCh5 HsYfhYB161X_kTAFiFijTHG_cFcvLAS7v_faSgthY2qYc3dnq7VJOOjNUwl3Vuypl2Y0GCsfoLSa 5L9yGRP_7nz_vfnUFpRQrVUQEMscgOIfbznHZCVqtOs_RXJR6EDWApPZD11UIXYF6weIwfDWr1R. 0YBktMEUuFGJMuaDHkbKeUZAppaaHk8Nc.p5ZiPw.oZ9cItp_b3xZrX.OQkVVLsNMqv49mB62kWO JhynoMFCpEPPem17Qj8PRicdwpSsEqQIOOjmjdfjYWxrFOk8c5nFfLwEFKAYAfnp6rDoZpBGiShG xg1gm_LWKQePhB5pGUj7SD59zdufmFWLQy9.epqBQQ8d8EzkEEXtPqXH39k0RdiAZb3Tx3CvpXYi 1WALjXzXSZ1jp5I0XJLfRnyefANsQnWJgIoYAZYAoXzEBMx4RPpCEowONOwKJkk.XAVCa6nC4SoQ LOGXT5beA1Z0jfqqgF14RAhQ1sf84zyQK0MXvoNETDV.bizEcj2wr2K8Wn.JBAznHXjaPQYvUzN. 8B5URlAVuaFkZ8_N5mI.0gq2JLpZtvM0HB56Zf7gyakyty6OpFLc2ZnV1sfRowrpAuz1wqCM0Dy6 0iKztUJzRFJWdg..G1uD9Pea7T_M5StwyF6WXUrjVs.dPhjnn1a6iZLFFNl934u2su4o0_WoTWAz aS6hEiX7b2QQ6M8kr7t22R7jmAa7crJvO8OVTYSXfv.P928Jsg0FUCtQgBedB3PQJ4RY4wjnx_2h SGbDjVSg0drN4Q.doN7kr4RO3RiLdlyQ3Tvf1YKDPx1SE42WQJqQ_9aY3SlVHKD.nk.Pw6PROiNL Wn_c- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic316.consmr.mail.gq1.yahoo.com with HTTP; Thu, 23 Feb 2023 08:08:09 +0000 Received: by hermes--production-ne1-746bc6c6c4-b6fc9 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 746fe916046eb0e14074ece8bbce3ff0; Thu, 23 Feb 2023 08:08:05 +0000 (UTC) Content-Type: text/plain; charset=us-ascii 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 Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.400.51.1.1\)) Subject: Re: FYI: Why META_MODE rebuilds so much for building again after installworld (no source changes) From: Mark Millard In-Reply-To: <72419.1677133429@kaos.jnpr.net> Date: Thu, 23 Feb 2023 00:07:54 -0800 Cc: Bryan Drewery , Current FreeBSD , Peter Content-Transfer-Encoding: quoted-printable Message-Id: References: <3345EBA5-A09C-4E3F-B94D-39F57F56BDBB@yahoo.com> <73088.1611797582@kaos.jnpr.net> <10819.1677108389@kaos.jnpr.net> <76FA98EF-6184-4D7E-A01F-0EE8117D0D10@yahoo.com> <29887.1677115125@kaos.jnpr.net> <27790339-240F-4C97-97C7-38AFD8DE03D5@yahoo.com> <72419.1677133429@kaos.jnpr.net> To: "Simon J. Gerraty" X-Mailer: Apple Mail (2.3731.400.51.1.1) X-Rspamd-Queue-Id: 4PMlyM05T4z3hqd X-Spamd-Bar: ---- 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-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N On Feb 22, 2023, at 22:23, Simon J. Gerraty wrote: > Mark Millard wrote: >>>=20 >>> Is there anything under ${OBJTOP}/tmp that you don't want to ignore? >>=20 >> More than just _bootstrap_tools_links entries end up in >> ${WORLDTMP}/legacy/bin/ (so in ${WORLDTMP}/legacy/sbin/ >> via the symbolic link pointing to ${WORLDTMP}/legacy/bin/ ). >> So: yes. >>=20 >> Also, OBJTOP is not constant over all the parts of >> buildworld buildkernel . Having the late-substitution >> form of notation ${OBJTOP} might not be appropriate >> for the content of .MAKE.META.IGNORE_PATHS . >=20 > Fwiw .MAKE.META.IGNORE_PATHS is evaluated when meta_init() is > called after all the makefiles have been read - and had a > chance to influence .MAKE.MODE, so I'm not sure how varaiablity of > OBJTOP would matter? To my knowledge, there is no place to find documentation about when/how-often the .MAKE.META.IGNORE_PATHS original text is reevaluated other than the above statement or source code inspection. (Others have a similar status.) -dV -V.MAKE.META.IGNORE_PATHS use does list ${__MAKE_SHELL} but lists /bin/sh without the -dV . (So -V use does not give a direct clue at what you report.) I got past the issue using :=3D before reading the above. (I'm also using MAKEOBJDIR instead of OBJTOP currently.) >>> .MAKE.META.IGNORE_PATHS+=3D ${OBJTOP}/tmp/ >>=20 >> (Ignoring the variability of OBJTOP issue . . .) >>=20 >> I do not expect that would work: ignoring things >> it likely should not. >=20 > Sure, but it may be useful as an experiment to ensure things are > behaving as expected. As a test: .if ${.MAKE.LEVEL} =3D=3D 0 .MAKE.META.IGNORE_PATHS+=3D ${MAKEOBJDIR:tA}/tmp/ .MAKE.META.IGNORE_PATHS:=3D ${.MAKE.META.IGNORE_PATHS} .endif leads to: # = ~/sys-build-scripts.amd64-host/make-main-amd64-nodbg-clang.amd64-host.sh = -dV -V.MAKE.META.IGNORE_PATHS buildworld buildkernel Script started, output file is = /usr/obj/BUILDs/main-amd64-nodbg-clang/sys-typescripts/typescript-make-amd= 64-nodbg-clang-amd64-host-2023-02-22:23:29:01 ${__MAKE_SHELL} /bin /lib /rescue /sbin /usr/bin /usr/lib = /usr/sbin /usr/share /usr/include /usr/local/etc/libmap.d = /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/tmp/ Script done, output file is = /usr/obj/BUILDs/main-amd64-nodbg-clang/sys-typescripts/typescript-make-amd= 64-nodbg-clang-amd64-host-2023-02-22:23:29:01 Note: I'm currently avoiding -jN for 1> Also, I'd rather grow a smaller set of ignores >> gradually to make it easier to detect if an >> addition starts causing a problem and can be >> backed out. Starting with everything ignored >> would make things much harder to figure out >> when ignoring creates a problem. >=20 > Yes. >=20 >>=20 >>> You might need ${OBJTOP:tA}/tmp/ >>> or both. >=20 > I found it necessary in the unit tests to add :tA to both TMPDIR > and .OBJDIR to get sane result on one test platform. >=20 >>>> It is using paths that match the -dM output lines ( sbin >>>> use despite sbin -> ../bin being a symbolic link). >=20 > use :tA if you want to ensure consistent results. So, for each: .MAKE.META.IGNORE_PATHS+=3D = ${MAKEOBJDIR}/tmp/legacy/usr/sbin/${ignore_legacy_tool} I need to form an overall :tA on the path? Something like: .if ${.MAKE.LEVEL} =3D=3D 0 .for ignore_legacy_tool in awk cap_mkdb cat cp crunchgen crunchide dd = egrep env file2c gencat grep gzip jot lex lb ln m4 mkcsmapper mktemp mv = patch realpath rm sed sh touch truncate uudecode uuencode xargs IGNORELEGACY_${ignore_legacy_tool}=3D = ${MAKEOBJDIR}/tmp/legacy/usr/sbin/${ignore_legacy_tool} .MAKE.META.IGNORE_PATHS+=3D ${IGNORELEGACY_${ignore_legacy_tool}:tA} .endfor .for ignore_other_tool in ctfconvert objcopy nm IGNOREOTHER_${ignore_other_tool}=3D = ${MAKEOBJDIR}/tmp/usr/bin/${ignore_other_tool} .MAKE.META.IGNORE_PATHS+=3D ${IGNOREOTHER_${ignore_other_tool}:tA} .endfor .MAKE.META.IGNORE_PATHS:=3D ${.MAKE.META.IGNORE_PATHS} .endif Such seems to make no difference to the text reported via -dV -V.MAKE.META.IGNORE_PATHS in my context. >>> I really need to add some unit-tests for these... >=20 > Done - not yet imported to FreeBSD though >=20 >> You may want to wait while I see if I can come up with >> a better example context to show things. I only just >> noticed the late-substitution potential issue and >> started looking for a way to avoid it, for example. >> (Either a value that does not vary or a form of >> causing up-front substitutions in my make.conf .) >=20 > Ok =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Thu Feb 23 09:27:16 2023 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 4PMnjh3bN3z3tFjt for ; Thu, 23 Feb 2023 09:27:20 +0000 (UTC) (envelope-from gbe@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4PMnjh36dnz3pJ6; Thu, 23 Feb 2023 09:27:20 +0000 (UTC) (envelope-from gbe@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1677144440; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=J8JZm8mMbLBRu2lrN7HDzhWsOVX35eLaIcu3V8Nuj7I=; b=DXH1jFMWW0frkVqkr9oBOHAtGf2SKK8GNlC553e86iUL9MN3r9y0TaohghuHPuIBiLkSVm i742vigyvYJsVyS5yjcvP6XAIg0tZdaS0HUg3nKc5iSGl7zS8IGWjwYFvozdpyjJeQ/K7F DGhd8FHjPSUGV+EChOwQeWCBZwChk0YFZnobj4W3Q68zdqJppGw4gX50zV64pYaXqZs0f0 Jq/McNvYBBuVtdScFAsJewYeNRO05DNHkTQG4rvwhMUZK2G1QIZRVPABd3TM7hEz/XZTJz Pwe6ScU8erg3M1jY4dwj9+kHL9imqGwMnDp+2r0LPkJVlgyCJkvxo3SHhtHS/w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1677144440; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=J8JZm8mMbLBRu2lrN7HDzhWsOVX35eLaIcu3V8Nuj7I=; b=F3nhPKwqFZHk5vCNBeEHbRNQx2bY+myjDFxfnE5hRYhyoBa/GUYxr25H1NpKqtz1V6hcZO nTX0Y+VlmS9aujzjPJtkSE4fDINoyJmCevQGNigXzkzVBvYwfWa5ZRfRr0iKCasDDwb0Iu shE6XB1E3s1XGOdJABtA5W0TpHdidzhaGyesVit9bHbaPEZdYxkVb1UKDMBlgS+kpNuCbJ ybSs4CHDVMi5CRucA4QRlLA/bo/GyJOVD7V9GlXoRg2PUIanCPYDXhZklnUAOsEWrFGiwT pZ74muzVwGTzEtGMN5w7X8vfYmJ4DM2jr/cXvCmewtpEEi/SnwEcx8YnWe8DKw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1677144440; a=rsa-sha256; cv=none; b=I3dOm6VonBRN0Q0aqTA6V8cxTfX2r1ydhiP1yx3Md0F3LFymU6PLxCjPHJl7VjEYKrxkri CdmU5VTUG6fAd8UG4aR0NOT5dOsx7sHdkHFDLbVhGW6QAO/hix3pk93LflZDTYBcAB+X7o 24mB8pvBCxVas7+rZvBiRQ0RuD/6bplQHTdQkanzBNZ8kIVvRc7C2ZHHs9Ao7fCN0AIC+x MDp8TPLzExuFkJbRyn9i5SuMpjvf/jd0gJbdPntLfe+p6KyoKhmIU84c9HV4qIPAdc86H0 DSfuR+bYsF9Uj2SHi+sMKSze2BSm/xF5O+4oJJTgMpzLbY9TBOHbexh33R7HeQ== Received: from localhost (p200300cb871a692ba910bafe31b14fc0.dip0.t-ipconnect.de [IPv6:2003:cb:871a:692b:a910:bafe:31b1:4fc0]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: gbe) by smtp.freebsd.org (Postfix) with ESMTPSA id 4PMnjg6bVbzPTv; Thu, 23 Feb 2023 09:27:19 +0000 (UTC) (envelope-from gbe@freebsd.org) Date: Thu, 23 Feb 2023 10:27:16 +0100 From: Gordon Bergling To: "Simon J. Gerraty" Cc: Warner Losh , FreeBSD Current Subject: Re: Build breakage with WITH_BEARSSL=1 Message-ID: References: <7363.1676957028@kaos.jnpr.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 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="u/TNmW/lNR+jTeoZ" Content-Disposition: inline In-Reply-To: <7363.1676957028@kaos.jnpr.net> X-Url: X-Operating-System: FreeBSD 13.2-STABLE amd64 X-Host-Uptime: 10:23AM up 6 days, 3:54, 2 users, load averages: 0.23, 0.37, 1.01 X-ThisMailContainsUnwantedMimeParts: N --u/TNmW/lNR+jTeoZ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi Simon, On Mon, Feb 20, 2023 at 09:23:48PM -0800, Simon J. Gerraty wrote: > This has been fixed upstream, I'll look at importing an update. Thanks for merging the upstream fix. BearSSL is now compiling, but I get a different error now while building veriexec. /boiler/nfs/src/sbin/veriexec/veriexec.c:53:15: error: a function declaration without a prototype is deprecated in all versio ns of C [-Werror,-Wstrict-prototypes] veriexec_usage() ^ void This looks to me, that the Makefile of veriexec should be updated as well. --Gordon --u/TNmW/lNR+jTeoZ Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGTBAEBCgB9FiEEYbWI0KY5X7yH/Fy4OQX2V8rP09wFAmP3MXNfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDYx QjU4OEQwQTYzOTVGQkM4N0ZDNUNCODM5MDVGNjU3Q0FDRkQzREMACgkQOQX2V8rP 09wlSQgA6E52SwIQsMzNtAcR4e8s7FVjQLPUKAi7Xj5cJDH9XjK40uxIldOD2u/r 1MGe7G6rm3n+lbgHvVpNPjDTNl94xP04PVdox/JvH/NP9bZgVNgER+hi9ejxft4F XFaGaBFxCr1ZGfKNfq/lyphiTGraGsUyCVqzYs23yAStND2Ziy+PkfhrpnSRu3dQ q0EsAg1ia8hb05f5DVJ58FU684H7Im0X7rRkiXs3+xZhMHzFBW8GTGsb+ObiAEz9 Rx6ngOAbPQWjejWXJxsMZc/IUO28CQMw8229tCrgnY7jsyOeFVVM+rfPmS6+i2CW oYz1AU+VYH5LOoquPX48lND3ZdAOxQ== =la5D -----END PGP SIGNATURE----- --u/TNmW/lNR+jTeoZ-- From nobody Thu Feb 23 09:57:02 2023 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 4PMpNJ593Rz3tGky for ; Thu, 23 Feb 2023 09:57:20 +0000 (UTC) (envelope-from freebsd@igalic.co) Received: from mail-40136.proton.ch (mail-40136.proton.ch [185.70.40.136]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "protonmail.com", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4PMpNJ2mVZz3rc8 for ; Thu, 23 Feb 2023 09:57:20 +0000 (UTC) (envelope-from freebsd@igalic.co) Authentication-Results: mx1.freebsd.org; none Date: Thu, 23 Feb 2023 09:57:02 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=igalic.co; s=protonmail; t=1677146237; x=1677405437; bh=blkwn4yk0gilWXjiophuJKlz8mD39iZNkQDRFkjM4AM=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=lGs8gf3UcPsGpsEMmC04TdLUUcsAn/10aBRvlVVPUphuW0eGzsfl0+x0uRCknPrjJ 5GCrHMzs8F69ajStr510pu8omR0gZ4bTZ7fbbsit/RGZH9cKPmCPKR2+u3IshL42Hf kpbq6sP+Vh9PYS9JZquUJe6CDgP5HFHE7mrHrd8DPyoMbfqqmQpfXWI9600npkL9Mt XJcdNWV4GbvTJMhcCRv/1xawtBWj+KENvwHQjU1YaPRVsNzOV7FFZbjduN7tZcCV53 fv8eqFeaaNKkUKmTld+pHuooPtGCEfFERLTmhgqSu004NvOk7RLn7icgOQZpY5jR+5 6Qk0Wwha+E7cw== To: gbe@freebsd.org, sjg@juniper.net From: =?utf-8?Q?Mina_Gali=C4=87?= Cc: imp@bsdimp.com, freebsd-current@freebsd.org Subject: Re: Build breakage with WITH_BEARSSL=1 Message-ID: In-Reply-To: References: <7363.1676957028@kaos.jnpr.net> Feedback-ID: 66573723:user:proton 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 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="b1_VIvyMKsEnm7ncGLK8RFE7RClD7IoH7UEmmE9w7oM" X-Rspamd-Queue-Id: 4PMpNJ2mVZz3rc8 X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:62371, ipnet:185.70.40.0/24, country:CH] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N This is a multi-part message in MIME format. --b1_VIvyMKsEnm7ncGLK8RFE7RClD7IoH7UEmmE9w7oM Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 Z2l2ZW4gdGhhdCB0aGlzIGlzbid0IGNvbnRyaWIgY29kZSwgd2UgY2FuIGp1c3QgZml4IGl0IGlu IG91ciB0cmVlOgoKaHR0cHM6Ly9naXRodWIuY29tL2ZyZWVic2QvZnJlZWJzZC1zcmMvYmxvYi9t YWluL3NiaW4vdmVyaWV4ZWMvdmVyaWV4ZWMuYyNMNTIKCk1pbmEgR2FsacSHCgpUcnkgUGtnQmFz ZTogaHR0cHM6Ly9hbHBoYS5wa2diYXNlLmxpdmUvCgotLS0tLS0tLSBPcmlnaW5hbCBNZXNzYWdl IC0tLS0tLS0tCk9uIDIzIEZlYiAyMDIzLCAwOToyNywgR29yZG9uIEJlcmdsaW5nIHdyb3RlOgoK PiBIaSBTaW1vbiwgT24gTW9uLCBGZWIgMjAsIDIwMjMgYXQgMDk6MjM6NDhQTSAtMDgwMCwgU2lt b24gSi4gR2VycmF0eSB3cm90ZTogPiBUaGlzIGhhcyBiZWVuIGZpeGVkIHVwc3RyZWFtLCBJJ2xs IGxvb2sgYXQgaW1wb3J0aW5nIGFuIHVwZGF0ZS4gVGhhbmtzIGZvciBtZXJnaW5nIHRoZSB1cHN0 cmVhbSBmaXguIEJlYXJTU0wgaXMgbm93IGNvbXBpbGluZywgYnV0IEkgZ2V0IGEgZGlmZmVyZW50 IGVycm9yIG5vdyB3aGlsZSBidWlsZGluZyB2ZXJpZXhlYy4gL2JvaWxlci9uZnMvc3JjL3NiaW4v dmVyaWV4ZWMvdmVyaWV4ZWMuYzo1MzoxNTogZXJyb3I6IGEgZnVuY3Rpb24gZGVjbGFyYXRpb24g d2l0aG91dCBhIHByb3RvdHlwZSBpcyBkZXByZWNhdGVkIGluIGFsbCB2ZXJzaW8gbnMgb2YgQyBb LVdlcnJvciwtV3N0cmljdC1wcm90b3R5cGVzXSB2ZXJpZXhlY191c2FnZSgpIF4gdm9pZCBUaGlz IGxvb2tzIHRvIG1lLCB0aGF0IHRoZSBNYWtlZmlsZSBvZiB2ZXJpZXhlYyBzaG91bGQgYmUgdXBk YXRlZCBhcyB3ZWxsLiAtLUdvcmRvbg== --b1_VIvyMKsEnm7ncGLK8RFE7RClD7IoH7UEmmE9w7oM Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 Z2l2ZW4gdGhhdCB0aGlzIGlzbid0IGNvbnRyaWIgY29kZSwgd2UgY2FuIGp1c3QgZml4IGl0IGlu IG91ciB0cmVlOjxicj48YnI+PGEgaHJlZj0iaHR0cHM6Ly9naXRodWIuY29tL2ZyZWVic2QvZnJl ZWJzZC1zcmMvYmxvYi9tYWluL3NiaW4vdmVyaWV4ZWMvdmVyaWV4ZWMuYyNMNTIiPmh0dHBzOi8v Z2l0aHViLmNvbS9mcmVlYnNkL2ZyZWVic2Qtc3JjL2Jsb2IvbWFpbi9zYmluL3ZlcmlleGVjL3Zl cmlleGVjLmMjTDUyPC9hPjxicj48YnI+PGJyPjxzcGFuPk1pbmEgR2FsacSHPC9zcGFuPjxkaXY+ PGJyIC8+PC9kaXY+PGRpdj5UcnkgUGtnQmFzZTogPGEgaHJlZj0iaHR0cHM6Ly9hbHBoYS5wa2di YXNlLmxpdmUvIiB0aXRsZT0iaHR0cHM6Ly9hbHBoYS5wa2diYXNlLmxpdmUvIj5odHRwczovL2Fs cGhhLnBrZ2Jhc2UubGl2ZS88L2E+PC9kaXY+PHNwYW4+PC9zcGFuPjxicj48YnI+PGJyPjxicj48 YnI+PGJyPi0tLS0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0tLS08YnI+T24gMjMgRmViIDIw MjMsIDA5OjI3LCBHb3Jkb24gQmVyZ2xpbmcgPCBnYmVAZnJlZWJzZC5vcmc+IHdyb3RlOjxibG9j a3F1b3RlIGNsYXNzPSJwcm90b25tYWlsX3F1b3RlIj48YnI+SGkgU2ltb24sDQoNCk9uIE1vbiwg RmViIDIwLCAyMDIzIGF0IDA5OjIzOjQ4UE0gLTA4MDAsIFNpbW9uIEouIEdlcnJhdHkgd3JvdGU6 DQo+IFRoaXMgaGFzIGJlZW4gZml4ZWQgdXBzdHJlYW0sIEknbGwgbG9vayBhdCBpbXBvcnRpbmcg YW4gdXBkYXRlLg0KDQpUaGFua3MgZm9yIG1lcmdpbmcgdGhlIHVwc3RyZWFtIGZpeC4gQmVhclNT TCBpcyBub3cgY29tcGlsaW5nLCBidXQgSSBnZXQgYQ0KZGlmZmVyZW50IGVycm9yIG5vdyB3aGls ZSBidWlsZGluZyB2ZXJpZXhlYy4NCg0KICAvYm9pbGVyL25mcy9zcmMvc2Jpbi92ZXJpZXhlYy92 ZXJpZXhlYy5jOjUzOjE1OiBlcnJvcjogYSBmdW5jdGlvbiBkZWNsYXJhdGlvbiB3aXRob3V0IGEg cHJvdG90eXBlIGlzIGRlcHJlY2F0ZWQgaW4gYWxsIHZlcnNpbyAgbnMgb2YgQyBbLVdlcnJvciwt V3N0cmljdC1wcm90b3R5cGVzXQ0KICB2ZXJpZXhlY191c2FnZSgpDQogICAgICAgICAgICAgICAg Xg0KICAgICAgICAgICAgICAgICB2b2lkDQoNClRoaXMgbG9va3MgdG8gbWUsIHRoYXQgdGhlIE1h a2VmaWxlIG9mIHZlcmlleGVjIHNob3VsZCBiZSB1cGRhdGVkIGFzIHdlbGwuDQoNCi0tR29yZG9u PC9kaXY+ --b1_VIvyMKsEnm7ncGLK8RFE7RClD7IoH7UEmmE9w7oM-- From nobody Thu Feb 23 10:05:25 2023 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 4PMpYq19kKz3tHQ5 for ; Thu, 23 Feb 2023 10:05:35 +0000 (UTC) (envelope-from freebsd@igalic.co) Received: from mail-40136.proton.ch (mail-40136.proton.ch [185.70.40.136]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits)) (Client CN "protonmail.com", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4PMpYn1Pnlz3tVC for ; Thu, 23 Feb 2023 10:05:33 +0000 (UTC) (envelope-from freebsd@igalic.co) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=igalic.co header.s=protonmail header.b=nfPtxIiI; spf=pass (mx1.freebsd.org: domain of freebsd@igalic.co designates 185.70.40.136 as permitted sender) smtp.mailfrom=freebsd@igalic.co; dmarc=none Date: Thu, 23 Feb 2023 10:05:25 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=igalic.co; s=protonmail; t=1677146732; x=1677405932; bh=u+DCL6JRKjAzB9Ou6mBla4823tN9e2H/D25AR3Vbfd4=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=nfPtxIiI36Sl7jwW6DbdjiaBTJCDZRDme8mHhFOE0N//rl+6pdEyLI6VWDaEdrV1r +N4n7EONX4sPX5s+ifhNf9ss8Fh+aEeZFOV1c0zntGNDGqV9vkPsE7LHaVRFuTHZgR mfpQvffcY6Xfz38CSfTv8UkVzwDYcwchgbsVmZOojIQ91KUtvCHEnT7pQ2a+o9zwwz ki0lCYWv8Glou4uKARGX5cwnHyBl39oQee2mHzNyM1fS+9h+ei/GAPkqxoGAK14Br+ UF1fuSTOb80cZJ4haES1LMY2/lOei7bRPwPhxxuTjfjBrbb6o+a6h+eOyEjcIyi4x9 B4DaZaQ+xruaw== To: Gordon Bergling From: =?utf-8?Q?Mina_Gali=C4=87?= Cc: imp@bsdimp.com, freebsd-current@freebsd.org Subject: Re: Build breakage with WITH_BEARSSL=1 Message-ID: In-Reply-To: References: <7363.1676957028@kaos.jnpr.net> Feedback-ID: 66573723:user:proton 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 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="b1_smsSgPI0mjNpJzT6uQGytAbkg06uM7SPhT6XNsgKTls" X-Spamd-Result: default: False [-2.77 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.99)[-0.995]; R_MIXED_CHARSET(0.63)[subject]; R_SPF_ALLOW(-0.20)[+ip4:185.70.40.0/24]; R_DKIM_ALLOW(-0.20)[igalic.co:s=protonmail]; MIME_BASE64_TEXT(0.10)[]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; FROM_EQ_ENVFROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; RCVD_COUNT_ZERO(0.00)[0]; MIME_TRACE(0.00)[0:+,1:+,2:~]; DKIM_TRACE(0.00)[igalic.co:+]; ARC_NA(0.00)[]; ASN(0.00)[asn:62371, ipnet:185.70.40.0/24, country:CH]; RCPT_COUNT_THREE(0.00)[3]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_SOME(0.00)[]; DMARC_NA(0.00)[igalic.co]; HAS_PHPMAILER_SIG(0.00)[]; MID_RHS_MATCH_FROM(0.00)[] X-Rspamd-Queue-Id: 4PMpYn1Pnlz3tVC X-Spamd-Bar: -- X-ThisMailContainsUnwantedMimeParts: N This is a multi-part message in MIME format. --b1_smsSgPI0mjNpJzT6uQGytAbkg06uM7SPhT6XNsgKTls Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 dGFraW5nIFNpbW9uIG9mZiB0aGUgbGlzdCwgY3V6IGhpcyBhdXRvIC0gcmVwbHkgaW5kaWNhdGVz IGhlJ3MgdmVyeSBidXN5LgoKRWl0aGVyIHdheSwgdCBzaG91bGQgZG8gaXQ6IGh0dHBzOi8vZ2l0 aHViLmNvbS9mcmVlYnNkL2ZyZWVic2Qtc3JjL3B1bGwvNjU3CgpNaW5hIEdhbGnEhwoKVHJ5IFBr Z0Jhc2U6IGh0dHBzOi8vYWxwaGEucGtnYmFzZS5saXZlLwoKLS0tLS0tLS0gT3JpZ2luYWwgTWVz c2FnZSAtLS0tLS0tLQpPbiAyMyBGZWIgMjAyMywgMDk6NTcsIE1pbmEgR2FsacSHIHdyb3RlOgoK PiBnaXZlbiB0aGF0IHRoaXMgaXNuJ3QgY29udHJpYiBjb2RlLCB3ZSBjYW4ganVzdCBmaXggaXQg aW4gb3VyIHRyZWU6Cj4KPiBodHRwczovL2dpdGh1Yi5jb20vZnJlZWJzZC9mcmVlYnNkLXNyYy9i bG9iL21haW4vc2Jpbi92ZXJpZXhlYy92ZXJpZXhlYy5jI0w1Mgo+Cj4gTWluYSBHYWxpxIcKPgo+ IFRyeSBQa2dCYXNlOiBodHRwczovL2FscGhhLnBrZ2Jhc2UubGl2ZS8KPgo+IC0tLS0tLS0tIE9y aWdpbmFsIE1lc3NhZ2UgLS0tLS0tLS0KPiBPbiAyMyBGZWIgMjAyMywgMDk6MjcsIEdvcmRvbiBC ZXJnbGluZyB3cm90ZToKPgo+PiBIaSBTaW1vbiwgT24gTW9uLCBGZWIgMjAsIDIwMjMgYXQgMDk6 MjM6NDhQTSAtMDgwMCwgU2ltb24gSi4gR2VycmF0eSB3cm90ZTogPiBUaGlzIGhhcyBiZWVuIGZp eGVkIHVwc3RyZWFtLCBJJ2xsIGxvb2sgYXQgaW1wb3J0aW5nIGFuIHVwZGF0ZS4gVGhhbmtzIGZv ciBtZXJnaW5nIHRoZSB1cHN0cmVhbSBmaXguIEJlYXJTU0wgaXMgbm93IGNvbXBpbGluZywgYnV0 IEkgZ2V0IGEgZGlmZmVyZW50IGVycm9yIG5vdyB3aGlsZSBidWlsZGluZyB2ZXJpZXhlYy4gL2Jv aWxlci9uZnMvc3JjL3NiaW4vdmVyaWV4ZWMvdmVyaWV4ZWMuYzo1MzoxNTogZXJyb3I6IGEgZnVu Y3Rpb24gZGVjbGFyYXRpb24gd2l0aG91dCBhIHByb3RvdHlwZSBpcyBkZXByZWNhdGVkIGluIGFs bCB2ZXJzaW8gbnMgb2YgQyBbLVdlcnJvciwtV3N0cmljdC1wcm90b3R5cGVzXSB2ZXJpZXhlY191 c2FnZSgpIF4gdm9pZCBUaGlzIGxvb2tzIHRvIG1lLCB0aGF0IHRoZSBNYWtlZmlsZSBvZiB2ZXJp ZXhlYyBzaG91bGQgYmUgdXBkYXRlZCBhcyB3ZWxsLiAtLUdvcmRvbg== --b1_smsSgPI0mjNpJzT6uQGytAbkg06uM7SPhT6XNsgKTls Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 dGFraW5nIFNpbW9uIG9mZiB0aGUgbGlzdCwgY3V6IGhpcyBhdXRvIC0gcmVwbHkgaW5kaWNhdGVz IGhlJiMzOTtzIHZlcnkgYnVzeS48YnI+PGJyPkVpdGhlciB3YXksIHQgc2hvdWxkIGRvIGl0OiA8 YSBocmVmPSJodHRwczovL2dpdGh1Yi5jb20vZnJlZWJzZC9mcmVlYnNkLXNyYy9wdWxsLzY1NyI+ aHR0cHM6Ly9naXRodWIuY29tL2ZyZWVic2QvZnJlZWJzZC1zcmMvcHVsbC82NTc8L2E+PGJyPjxi cj48YnI+PHNwYW4+TWluYSBHYWxpxIc8L3NwYW4+PGRpdj48YnIgLz48L2Rpdj48ZGl2PlRyeSBQ a2dCYXNlOiA8YSBocmVmPSJodHRwczovL2FscGhhLnBrZ2Jhc2UubGl2ZS8iIHRpdGxlPSJodHRw czovL2FscGhhLnBrZ2Jhc2UubGl2ZS8iPmh0dHBzOi8vYWxwaGEucGtnYmFzZS5saXZlLzwvYT48 L2Rpdj48c3Bhbj48L3NwYW4+PGJyPjxicj48YnI+PGJyPjxicj48YnI+LS0tLS0tLS0gT3JpZ2lu YWwgTWVzc2FnZSAtLS0tLS0tLTxicj5PbiAyMyBGZWIgMjAyMywgMDk6NTcsIE1pbmEgR2FsacSH IDwgZnJlZWJzZEBpZ2FsaWMuY28+IHdyb3RlOjxibG9ja3F1b3RlIGNsYXNzPSJwcm90b25tYWls X3F1b3RlIj48YnI+Z2l2ZW4gdGhhdCB0aGlzIGlzbid0IGNvbnRyaWIgY29kZSwgd2UgY2FuIGp1 c3QgZml4IGl0IGluIG91ciB0cmVlOjxicj48YnI+PGEgaHJlZj0iaHR0cHM6Ly9naXRodWIuY29t L2ZyZWVic2QvZnJlZWJzZC1zcmMvYmxvYi9tYWluL3NiaW4vdmVyaWV4ZWMvdmVyaWV4ZWMuYyNM NTIiPmh0dHBzOi8vZ2l0aHViLmNvbS9mcmVlYnNkL2ZyZWVic2Qtc3JjL2Jsb2IvbWFpbi9zYmlu L3ZlcmlleGVjL3ZlcmlleGVjLmMjTDUyPC9hPjxicj48YnI+PGJyPjxzcGFuPk1pbmEgR2FsacSH PC9zcGFuPjxkaXY+PGJyIC8+PC9kaXY+PGRpdj5UcnkgUGtnQmFzZTogPGEgaHJlZj0iaHR0cHM6 Ly9hbHBoYS5wa2diYXNlLmxpdmUvIiB0aXRsZT0iaHR0cHM6Ly9hbHBoYS5wa2diYXNlLmxpdmUv Ij5odHRwczovL2FscGhhLnBrZ2Jhc2UubGl2ZS88L2E+PC9kaXY+PHNwYW4+PC9zcGFuPjxicj48 YnI+PGJyPjxicj48YnI+PGJyPi0tLS0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0tLS08YnI+ T24gMjMgRmViIDIwMjMsIDA5OjI3LCBHb3Jkb24gQmVyZ2xpbmcgPCBnYmVAZnJlZWJzZC5vcmc+ IHdyb3RlOjxibG9ja3F1b3RlIGNsYXNzPSJwcm90b25tYWlsX3F1b3RlIj48YnI+SGkgU2ltb24s DQoNCk9uIE1vbiwgRmViIDIwLCAyMDIzIGF0IDA5OjIzOjQ4UE0gLTA4MDAsIFNpbW9uIEouIEdl cnJhdHkgd3JvdGU6DQo+IFRoaXMgaGFzIGJlZW4gZml4ZWQgdXBzdHJlYW0sIEknbGwgbG9vayBh dCBpbXBvcnRpbmcgYW4gdXBkYXRlLg0KDQpUaGFua3MgZm9yIG1lcmdpbmcgdGhlIHVwc3RyZWFt IGZpeC4gQmVhclNTTCBpcyBub3cgY29tcGlsaW5nLCBidXQgSSBnZXQgYQ0KZGlmZmVyZW50IGVy cm9yIG5vdyB3aGlsZSBidWlsZGluZyB2ZXJpZXhlYy4NCg0KICAvYm9pbGVyL25mcy9zcmMvc2Jp bi92ZXJpZXhlYy92ZXJpZXhlYy5jOjUzOjE1OiBlcnJvcjogYSBmdW5jdGlvbiBkZWNsYXJhdGlv biB3aXRob3V0IGEgcHJvdG90eXBlIGlzIGRlcHJlY2F0ZWQgaW4gYWxsIHZlcnNpbyAgbnMgb2Yg QyBbLVdlcnJvciwtV3N0cmljdC1wcm90b3R5cGVzXQ0KICB2ZXJpZXhlY191c2FnZSgpDQogICAg ICAgICAgICAgICAgXg0KICAgICAgICAgICAgICAgICB2b2lkDQoNClRoaXMgbG9va3MgdG8gbWUs IHRoYXQgdGhlIE1ha2VmaWxlIG9mIHZlcmlleGVjIHNob3VsZCBiZSB1cGRhdGVkIGFzIHdlbGwu DQoNCi0tR29yZG9uPC9kaXY+PC9kaXY+ --b1_smsSgPI0mjNpJzT6uQGytAbkg06uM7SPhT6XNsgKTls-- From nobody Thu Feb 23 10:57:18 2023 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 4PMqjW6QpJz3tZtr for ; Thu, 23 Feb 2023 10:57:19 +0000 (UTC) (envelope-from gbe@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4PMqjW5ySgz411N; Thu, 23 Feb 2023 10:57:19 +0000 (UTC) (envelope-from gbe@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1677149839; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=8udl6k/aiHry6kT3quNsccjF0VGYk5UQjamcORIrn4g=; b=ZeSmmj4d6oyhcETr6kXNb5ZxQAzfvXLtlLQ4XlwNFEQKWF74c01TJKh7mCMm80RAq897+T 9B+INTbnYhV/LkeptekOrSkEc5yOhMj1Pn8qabxzS7RHwMjpNzPbiLaS3P4LHSU7nFSImt Y3n76AXi91oHLt4S/bzK4mlIwt8NnUl3AYgiax48RA8zhyPA1wnOF3PAPTmPPvDqxzWyIS nNbsRdGo/iGwi4Sse9i0ky+NdfuAGB6hudV5jRxW90Sui1vUi8cSvZQMYRfNMdEDioKPjt cgYkeYLRAPZQm6qhJDzdOa9iwOVdly3pjwGcPLhd4OkTo1XtrzwZrasA3iCTyg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1677149839; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=8udl6k/aiHry6kT3quNsccjF0VGYk5UQjamcORIrn4g=; b=M0sH59P9gjF6C8rFYmBqPcZGIG18haWtMLBr72OAeOuFcC3aR5FQ0fAscia5Dj3/I/sVT7 zOzfOjkkPwXSub9NlLyna8URtD3Ef17fh68QpYyQZbIZz0TmgJNizpVCl/31CdNHCMc6ri lqpoCI+Xa15wnYMsGut5rQgTdwaw/7mXsyg0NSKwiUuaojIm9LogMn01MBu5ywDhXaH5p5 xGr82rTQ6aulJTIW5VFEtUn7d+0hfRrqrzH7vVPV0dzNic/xcy6+R9isC5aW4T8/ZSKIl2 YV00EEshD6RLvYXiqnX/MtCchVGvTa4NdZ8fQjSKD/EVcmsz0aozyrFoHNxn3g== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1677149839; a=rsa-sha256; cv=none; b=RKLDVYxw72SDqKDIFOHE81whVqsVLGxRucQj7RZbtexSTw70nEp8kptvnD4YVVVroU8FU1 ZqpI25LFSqshjVY6fBuAWvSKbR+QBGyifCU9PilYpstP33fSHD1aIq/Y2zKWmI9s4yPUje A48oMLmBlUVHgbQzM5kFbVzjKTiUSlgSvg/E0iwn6eft8kdfvXeQFGsyu4jCus/wWFLg3P bXr8KiE4RnPFutoGjpH5eOZmP/nyAN2uvSLWmBAN2Z+SVlgxg1gok68cPvLMa89vxEhxwH F4ozQ3StyZGNEiiqyMF9es/h/XB9vq6xIJTNqiG0FXLHFakCEv8802w1fsbSQg== Received: from localhost (p200300cb871a692ba910bafe31b14fc0.dip0.t-ipconnect.de [IPv6:2003:cb:871a:692b:a910:bafe:31b1:4fc0]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: gbe) by smtp.freebsd.org (Postfix) with ESMTPSA id 4PMqjW18cQzQhV; Thu, 23 Feb 2023 10:57:19 +0000 (UTC) (envelope-from gbe@freebsd.org) Date: Thu, 23 Feb 2023 11:57:18 +0100 From: Gordon Bergling To: Mina =?utf-8?B?R2FsacSH?= Cc: imp@bsdimp.com, freebsd-current@freebsd.org Subject: Re: Build breakage with WITH_BEARSSL=1 Message-ID: References: <7363.1676957028@kaos.jnpr.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 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Url: X-Operating-System: FreeBSD 13.2-STABLE amd64 X-Host-Uptime: 11:54AM up 6 days, 5:25, 2 users, load averages: 0.40, 0.32, 0.27 X-ThisMailContainsUnwantedMimeParts: N Hello Mina, thanks for the PR, I can confirm that this bugfix is working. @Warner, could you commit it? I think creating a differential for the small change isn't neccessary. --Gordon On Thu, Feb 23, 2023 at 10:05:25AM +0000, Mina Galić wrote: > taking Simon off the list, cuz his auto - reply indicates he's very busy. > > Either way, t should do it: https://github.com/freebsd/freebsd-src/pull/657 > > Mina Galić > > Try PkgBase: https://alpha.pkgbase.live/ > > -------- Original Message -------- > On 23 Feb 2023, 09:57, Mina Galić wrote: > > > given that this isn't contrib code, we can just fix it in our tree: > > > > https://github.com/freebsd/freebsd-src/blob/main/sbin/veriexec/veriexec.c#L52 > > > > Mina Galić > > > > Try PkgBase: https://alpha.pkgbase.live/ > > > > -------- Original Message -------- > > On 23 Feb 2023, 09:27, Gordon Bergling wrote: > > > >> Hi Simon, On Mon, Feb 20, 2023 at 09:23:48PM -0800, Simon J. Gerraty wrote: > This has been fixed upstream, I'll look at importing an update. Thanks for merging the upstream fix. BearSSL is now compiling, but I get a different error now while building veriexec. /boiler/nfs/src/sbin/veriexec/veriexec.c:53:15: error: a function declaration without a prototype is deprecated in all versio ns of C [-Werror,-Wstrict-prototypes] veriexec_usage() ^ void This looks to me, that the Makefile of veriexec should be updated as well. --Gordon -- From nobody Thu Feb 23 19:53:49 2023 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 4PN3cv5Dd4z3sgL8 for ; Thu, 23 Feb 2023 19:54:07 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic310-21.consmr.mail.gq1.yahoo.com (sonic310-21.consmr.mail.gq1.yahoo.com [98.137.69.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 4PN3ct3F6rz4Dnq for ; Thu, 23 Feb 2023 19:54:06 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=WdTrT6P5; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.147 as permitted sender) smtp.mailfrom=marklmi@yahoo.com; dmarc=pass (policy=reject) header.from=yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1677182044; bh=4zpDXKbAlmB1EH2tuMI3l+vN0uoDiQoTJazVUDb7YLw=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=WdTrT6P5k4dMs2haV0OtDBjWq6EzLl6pReJghox+PynpNBmPuTsOJEAI5yuNOvp2zhMNsNd+NrtEG6d8KhGF90Yr0hnRnWqMLFceypfZkctW7JgFwJN2k5JdSiN/+9ktECNAua0d5bShwkSldVYc9g9sRG3ibRyZwGhCq9dnrWfrLI63Ql7xbLxXkUYZUUppYuodPleIFtAID0QPOZNhzvhrGlrUOLiBA7sCo1kVF3CJKApLVFmb5YxwUHWOuKH9Vu5i6Lqt3JVcM4Upqh0OI56QYLjCwXvtPKgurGox31bCXgyq5MlMQW1jCNCxzCsbNIGq2CQGvPO9u32eZnVjsQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1677182044; bh=JUjVklwd91WzX6mRjWOi5KBUPUV6nx3OcshTybH/W2M=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=Q4alG3IVjPFO8giJ5rOcBjE3vBK9/3v+0om3Xa+oSQNeU2XVqWiogYD62dSLPSrIUMJsRGCtIvzT9H9gujTsxN9E0IiyqmJ9vrlNSaxSODqmsk47aKlaXfG3/S79C5yswRczDHgPHAGcz4AjOPr0Km6Le5XXCO/43zspmpxGxFoWAMDJ+1NqK7dViCNb2ElaCSw1jgYBKLEEG4UyOPPVzDOm193BQT7naUunEmyn/pZuuNooFGbvd/KKOQoLSJy6WuwwviprMozlTIQH75kGPTIYJSLipmDtUEwrsaOTI44rqUJyx+xCkd0wQs2CStLZiN4LMXVGhAj6HkymMNdWFg== X-YMail-OSG: mIlcM_sVM1nscbs0txj_UmZPAyMbXv19qZ2C.u4X5foDR6tqui0Hotu8WJGpptE Sf3hlS67kcmL9gRw49sycXWWChGTYmKNtYYSQyfzA7fIHn3tp7aNZ0Nwrblnb5VBdr46WyI5T1Uq 1kTorUmHKWC9Icew29lG6CErzBFO_dfAqMfSuM_bMKEKV6q1ZpI1hB1GT6F3RtS8LCZZQ9qjDgrh 4yz2hQRhARDpyiwwIvMUI.F9qUi_YqxLc4ZGsjezZtvY1kuWawuqsrlZDH5WVwlAmACW_NxJz1.D 6zfgXeT4y9VUEKG.GPkR4vrtKORsKvPxfiqQIWnl02HP09QAOFN9T8Rb6XRco4K.oDM3MN6RCpAe nJwaj3VkxAcAv8cP6qOtwel5OZ3_JCyIiLtbs6sIgDCOf09CRtZxCnzyRX_s2v.M1iJOuLvR_Jmt 4nTOHRZj6.BRYuq2enw4qeIF26wVUDBuv5Kkxq2enVJLnNgF0FmXlu6sc.pZffz_CuwA48HhBggj s9OoTCRbgcnBmV7BowDwdyRmXoLFOQqO9UNli7LycFTRXAW6nBl.ndtWMfQAZLvv9rS7ylQZaWom TSkn1x0jbgQXyiaTfv9g7gpdPup1Mr2IjpcrQry6aL1mEANIyJ8wE7GEcffUxNxGKhD7BQIHWRIQ 5ajiuzRxeZcE0gk26ZHP5X0pRnl1xMT71dS4ogUOwmmdFGqrXdVNQeZul9nMAWDv24wUBDwZAz3P mZwctDKbyjx7w1YTZBw2CISTh3Fo.a5ScQP_DZ8hvzMgHRaIkVejrX__fBXa_GCXh4m2pdG0vbkS sakdi9Y0WVR0sSFhEhh2pZetY0u7sqltc1BNq4z_g4hjO9bO4oY897cWMWO_k24VMvYqYREdeteL VGmsl5jfd6.0wnncKdtYxsElNPF_iDQXD.ZIAYEauWoyfWVeIlLz4.csxw_iASKphmltp4kVz_tM RUEZiNfjwutj2ORUm_qlW2AVeVXqwxEZE2WS9hWJ7524vm3kBFjb2OdXNDXYTk0z6lyu_SuK4x7c m.NCfQSZdOaxTNZdDo0E_9eoCgHJRslrYXvQjKnTsvrVgiqIm1abdktzcAj0Ngu7vMrseq7ZKupD NbYRKB5INrGpc8TitZi3uQQCtuiFnKlys5DKUsrPlx5C2bO25zZ7fGLwbLyQODERbrtTRYck8Vo3 SHi3_diBQSVUIBLJqY9_iUAVbgREIBvn6x4d3kjLLfprGwB1WiqsmJV3xkeT.e_zCvg6v6L7zXr7 Dk5n566wVZhCrKjKvErTM3tUZHF97ezUMUoI_E7jzWSPaPwFpZnILa8CHlM2GCabCBcZoFl3uquO 8uR4bUMzXaI7wN1bjx0KHkR0l06we.ZdPuRiStUlxEWg1WKkv6vpCuqjsZYZvcq0UABnUv9vzGJC XN_M0Zd3o6EiH2iSSYif..N34mo..9cXKLedWZ4Cjef99heqdnV04eyH19u8ytf8LgAmnS0w3fTH a9ecbwshRP3wQFjaaMwZx._u8JhyZedwn7dg.o1MUJm9JPEKmxCrOodHFOIjKgAeaVy.cQQjFt2W xR.AUugyMRDKMWZg7Y_1Rft03uwjcFmFOU5xZ3JfiAsYIbMlewkyOzGXU96ftDwdIFYFpzaPTMMX OT05bL9QOXZ6E3vvRu927gG7JUlZmSG3fq1XQJHdkixy689EGY4rLFzhPiTBXUmSX7vS.XtHchUT 4GvWm0ayvV_SE1veprO_NhzqfhdzugNlg4LVSGQRPt64gsqsZC9h6V2pwjZmxHql6ZeLf7W2BZzq q2Q9.N6QJvA00zVPF8VPrwOJW2LvhJfHseS4G05N5YvTGmlIFEfvQoTLrYsRmQ42QhSKs7mR3TKQ F9BV4CWsm_ed5W65E23mHoAReHBeoMKzvx_BWBqOlVLqlf.EtRu5aImC49skYXG1zomL3hyaAo.2 _lwzZArJYw1ocM6drfxAloah.zC019slrqU.luXA2jCFnKjn2ybdkVeSxc7ZrmTQbzEROGtwpG7J nXju8gM6.SxRK5MkC9V.eLmSMGfF6KZD1O3_kaePJxjdWQ4DiGNC76E8iKjKp8iovViqiUg_x54y XhmeiR30uglQRMm4xgNU.V0hD75xRXCIf52pj5cPUVyLox3kpBWXGoBAjODVqi4OccPftLsfOZgG 1VAR31FjO_RKjnbOgH_J0kCArpQSMBf_nm0CARkmrw0vKu0tYvIbdOLWcecoPfcXvWPwS3D6OWhk FZBedpXoXNLlwUCda5M.OJJ0hgbJtQ5XyzOUnOsr5hNB.Qy29RAeRz59Yc1C83MHCj6cdi_iFGYE CgxM- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic310.consmr.mail.gq1.yahoo.com with HTTP; Thu, 23 Feb 2023 19:54:04 +0000 Received: by hermes--production-bf1-57c96c66f6-p9vmd (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID c4317a4ce1bf7328f8478cb0b1109b3f; Thu, 23 Feb 2023 19:54:02 +0000 (UTC) Content-Type: text/plain; charset=us-ascii 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 Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.400.51.1.1\)) Subject: Re: FYI: Why META_MODE rebuilds so much for building again after installworld (no source changes) [code level bug evidence] From: Mark Millard In-Reply-To: Date: Thu, 23 Feb 2023 11:53:49 -0800 Cc: Bryan Drewery , Current FreeBSD , Peter Content-Transfer-Encoding: quoted-printable Message-Id: <266ED18F-9249-46BB-BF96-1D4C5B46FCFC@yahoo.com> References: <3345EBA5-A09C-4E3F-B94D-39F57F56BDBB@yahoo.com> <73088.1611797582@kaos.jnpr.net> <10819.1677108389@kaos.jnpr.net> <76FA98EF-6184-4D7E-A01F-0EE8117D0D10@yahoo.com> <29887.1677115125@kaos.jnpr.net> <27790339-240F-4C97-97C7-38AFD8DE03D5@yahoo.com> <72419.1677133429@kaos.jnpr.net> To: "Simon J. Gerraty" X-Mailer: Apple Mail (2.3731.400.51.1.1) X-Spamd-Result: default: False [-3.49 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.99)[-0.986]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; MV_CASE(0.50)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; MIME_GOOD(-0.10)[text/plain]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RCVD_IN_DNSWL_NONE(0.00)[98.137.69.147:from]; TO_DN_ALL(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; FREEMAIL_FROM(0.00)[yahoo.com]; RCVD_TLS_LAST(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; MIME_TRACE(0.00)[0:+]; FROM_EQ_ENVFROM(0.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; MLMMJ_DEST(0.00)[freebsd-current@FreeBSD.org] X-Rspamd-Queue-Id: 4PN3ct3F6rz4Dnq X-Spamd-Bar: --- X-ThisMailContainsUnwantedMimeParts: N cached_realpath only reports its "cached_realpath:" notice (not the purging one) when it does not find the value via HashTable_FindValue and so does a HashTable_Set : const char * cached_realpath(const char *pathname, char *resolved) { const char *rp; if (pathname =3D=3D NULL || pathname[0] =3D=3D '\0') return NULL; rp =3D HashTable_FindValue(&cached_realpaths, pathname); if (rp !=3D NULL) { /* a hit */ strncpy(resolved, rp, MAXPATHLEN); resolved[MAXPATHLEN - 1] =3D '\0'; return resolved; } rp =3D realpath(pathname, resolved); if (rp !=3D NULL) { HashTable_Set(&cached_realpaths, pathname, = bmake_strdup(rp)); DEBUG2(DIR, "cached_realpath: %s -> %s\n", pathname, = rp); return resolved; } /* should we negative-cache? */ return NULL; } cached_realpaths is global: static HashTable cached_realpaths; So with -ddM why do I see lots of "cached_realpath:" notices for the same path? For example: # grep "tmp/legacy/usr/sbin/ln\>" = /usr/obj/BUILDs/main-amd64-nodbg-clang/sys-typescripts/typescript-make-amd= 64-nodbg-clang-amd64-host-2023-02-23:10:20:26 | more cached_realpath: = /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/tmp/legacy= /usr/sbin/ln -> = /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/tmp/legacy= /bin/ln cached_realpath: = /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/tmp/legacy= /usr/sbin/ln -> = /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/tmp/legacy= /bin/ln Caching 02:49:37 Feb 23, 2023 for = /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/tmp/legacy= /usr/sbin/ln = /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/usr.bin/aw= k/awkgram.tab.h.meta: 22: file = '/usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/tmp/legac= y/usr/sbin/ln' is newer than the target... cached_realpath: = /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/tmp/legacy= /usr/sbin/ln -> = /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/tmp/legacy= /bin/ln Caching 02:49:37 Feb 23, 2023 for = /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/tmp/legacy= /usr/sbin/ln cached_realpath: = /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/tmp/legacy= /usr/sbin/ln -> = /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/tmp/legacy= /bin/ln Caching 02:49:37 Feb 23, 2023 for = /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/tmp/legacy= /usr/sbin/ln cached_realpath: = /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/tmp/legacy= /usr/sbin/ln -> = /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/tmp/legacy= /bin/ln Caching 02:49:37 Feb 23, 2023 for = /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/tmp/legacy= /usr/sbin/ln cached_realpath: = /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/tmp/legacy= /usr/sbin/ln -> = /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/tmp/legacy= /bin/ln Caching 02:49:37 Feb 23, 2023 for = /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/tmp/legacy= /usr/sbin/ln cached_realpath: = /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/tmp/legacy= /usr/sbin/ln -> = /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/tmp/legacy= /bin/ln Caching 02:49:37 Feb 23, 2023 for = /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/tmp/legacy= /usr/sbin/ln = /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/usr.bin/aw= k/awkgram.tab.h.meta: 22: file = '/usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/tmp/legac= y/usr/sbin/ln' is newer than the target... . . . A possible cause is something I ran into while looking around: /* A read-only range of a character array, NOT null-terminated. */ typedef struct Substring { const char *start; const char *end; } Substring; . . . MAKE_STATIC Substring Substring_Init(const char *start, const char *end) { Substring sub; sub.start =3D start; sub.end =3D end; return sub; } . . . /* Find the entry corresponding to the key, or return NULL. */ HashEntry * HashTable_FindEntry(HashTable *t, const char *key) { const char *keyEnd; unsigned int h =3D Hash_String(key, &keyEnd); return HashTable_Find(t, Substring_Init(key, keyEnd), h); } . . . /* A read-only range of a character array, NOT null-terminated. */ typedef struct Substring { const char *start; const char *end; } Substring; . . . MAKE_STATIC Substring Substring_Init(const char *start, const char *end) { Substring sub; sub.start =3D start; sub.end =3D end; return sub; } . . . /* Find the entry corresponding to the key, or return NULL. */ HashEntry * HashTable_FindEntry(HashTable *t, const char *key) { const char *keyEnd; unsigned int h =3D Hash_String(key, &keyEnd); return HashTable_Find(t, Substring_Init(key, keyEnd), h); } . . . /* This hash function matches Gosling's Emacs and java.lang.String. */ static unsigned int Hash_String(const char *key, const char **out_keyEnd) { unsigned int h; const char *p; h =3D 0; for (p =3D key; *p !=3D '\0'; p++) h =3D 31 * h + (unsigned char)*p; =20 *out_keyEnd =3D p; return h; } But after the loop: *p=3D=3D'\0' so *out_keyEnd=3D=3D'\0' and the FindEntry Substring_Init(key, keyEnd) ends up including the '\0' byte. But note that the h in Hash_String did not include the '\0' byte. Call this h value h_VALUE0 for later reference. Then look at: /* This hash function matches Gosling's Emacs and java.lang.String. */ unsigned int Hash_Substring(Substring key) { unsigned int h; const char *p; =20 h =3D 0; for (p =3D key.start; p !=3D key.end; p++) h =3D 31 * h + (unsigned char)*p; return h; } This h does include the '\0' byte so h=3D=3D(unsigned int)(31*h_VALUE0). I expect the mismatched hash values explain the repeated "cached_realpath:" notices for the same path: inserted but never found. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Thu Feb 23 20:15:34 2023 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 4PN47K6nLJz3sj38 for ; Thu, 23 Feb 2023 20:17:01 +0000 (UTC) (envelope-from sjg@juniper.net) Received: from mx0a-00273201.pphosted.com (mx0a-00273201.pphosted.com [208.84.65.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.pphosted.com", Issuer "Thawte RSA CA 2018" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4PN47K4FGDz4KXZ; Thu, 23 Feb 2023 20:17:01 +0000 (UTC) (envelope-from sjg@juniper.net) Authentication-Results: mx1.freebsd.org; none Received: from pps.filterd (m0108156.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 31NBstNk004316; Thu, 23 Feb 2023 12:16:37 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=to : cc : subject : in-reply-to : references : from : mime-version : content-type : content-id : content-transfer-encoding : date : message-id; s=PPS1017; bh=WzR+6zqFTXOgMgBEIs+hohIafWQvhFf/mTrUz5xu3Xk=; b=GSVndHO8/mNC6h0nQo4hbfoAbJmnuGeS6yicEOJ7QZRWvwZVefJVyccBrG/HY0PTHmcn X5YukaWxJm9xMBUg3KBfHmCogL3vaH7YTHBPNT/xG31RHKBs6aQZhdk+kD19gMQiICqV NgeMmK3zKcld1W9kFk5XTEK8R8nbkvfm3yZMQJezsCYJ8dphV7I8z+0RjhoJshqx1rWO VNXVUxs7Y/hW+QIFcaq+AqOy7voJOYvVkxWiQuE2ymT/qWaCNQAKL73Gtt6N0bvLykJM +NMOd8KePVrg9cMocu6Iku4OFFvD6Z9GXdxor17+rqEqsO8gHPJ+uS0vVP9GWuzksRMr 5g== Received: from dm4pr02cu001-vft-obe.outbound.protection.outlook.com (mail-centralusazlp17012023.outbound.protection.outlook.com [40.93.13.23]) by mx0a-00273201.pphosted.com (PPS) with ESMTPS id 3nwyb99kug-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 23 Feb 2023 12:16:36 -0800 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=HmThj0uxKqIRPpIKgNGpElkC08vxXnsHphAeYH17Z6U0lvf0sP+DkE3JalsMyDyfczg+hLc63mMlPrKp6KX0UI71dCVquw4JAY8X2Dj7G8CdSYDOuiNJXnlmbLpqVN+MIZzFVHn+VsK1o8iOaexsi3nFP82LKUx8rheJEYq8auGb5aetZ1L1oWKOLgPFTI5mg5JaDuBYw+CWsbRL6/Gx4CLm1MeVHzWGmb/aTBrG9glhpzlwufwpK2pRUACP3F/nHYjGRovNDJgrkEdGMoYoPRzcofq3WU/NJHqDcjEBXlFnstMLr709PfljjUI9xuL8cR5BgOwvczTUzqemTT2jNw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=WzR+6zqFTXOgMgBEIs+hohIafWQvhFf/mTrUz5xu3Xk=; b=F6IEGX8TFSQ+6nJXRXgTMbbreeEwBVaWVyCFRoiZjjDtVCpit8FKFpQuS6X5I3ISAlMySaMO5kVlRxYg3t3KVkwHz92mcJD4zLo977tHWvAXbRBdH8dzUbHYux5LBolAcHjN6XYXBvSxq8lFXuP3OpO/5YWO/950Fv6uqewEJryVvyF73HBrw2kNymuPmgH/MQvaEQGAgJWRLnRzNebBp2+2tnkUYi4PRuPkpO1NfVPtkGIlMUEDcsbufZzK+991F6nigwitGrFyK4AbtCx1R4+wRA3nykWLf53gRp6TNv6TE1mqFyVTrUGJm+0AprwyHyuQS5CRTiasMWC/+qVtBQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=softfail (sender ip is 66.129.239.14) smtp.rcpttodomain=yahoo.com smtp.mailfrom=juniper.net; dmarc=fail (p=reject sp=reject pct=100) action=oreject header.from=juniper.net; dkim=none (message not signed); arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=WzR+6zqFTXOgMgBEIs+hohIafWQvhFf/mTrUz5xu3Xk=; b=XBzaYok4zNUBavQMc36+wBvXRtxeSEkD1zG3OIaNq57yRytcveR94AL7rIbvtwoa2t9c3byc2q2opH3xcq+XN8LY9IkGQNTLP9TT6/EH8xandvZP1q1cgOVy3ocY9L3GbiDdR0NzXp6Df7rhqO4hIxPvNoPbnE5YmgvvUIXlFGE= Received: from MW4PR04CA0319.namprd04.prod.outlook.com (2603:10b6:303:82::24) by DS0PR05MB9719.namprd05.prod.outlook.com (2603:10b6:8:14d::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6111.18; Thu, 23 Feb 2023 20:16:34 +0000 Received: from MW2NAM12FT087.eop-nam12.prod.protection.outlook.com (2603:10b6:303:82:cafe::5a) by MW4PR04CA0319.outlook.office365.com (2603:10b6:303:82::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6134.21 via Frontend Transport; Thu, 23 Feb 2023 20:16:34 +0000 X-MS-Exchange-Authentication-Results: spf=softfail (sender IP is 66.129.239.14) smtp.mailfrom=juniper.net; dkim=none (message not signed) header.d=none;dmarc=fail action=oreject header.from=juniper.net; Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.14 as permitted sender) Received: from p-exchfe-eqx-01.jnpr.net (66.129.239.14) by MW2NAM12FT087.mail.protection.outlook.com (10.13.181.176) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6134.17 via Frontend Transport; Thu, 23 Feb 2023 20:16:34 +0000 Received: from p-exchbe-eqx-01.jnpr.net (10.104.9.14) by p-exchfe-eqx-01.jnpr.net (10.104.9.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.30; Thu, 23 Feb 2023 14:16:34 -0600 Received: from p-exchbe-eqx-01.jnpr.net (10.104.9.14) by p-exchbe-eqx-01.jnpr.net (10.104.9.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.30; Thu, 23 Feb 2023 14:16:33 -0600 Received: from p-mailhub01.juniper.net (10.104.20.6) by p-exchbe-eqx-01.jnpr.net (10.104.9.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.30 via Frontend Transport; Thu, 23 Feb 2023 14:16:33 -0600 Received: from kaos.jnpr.net (kaos.jnpr.net [172.23.255.201]) by p-mailhub01.juniper.net (8.14.4/8.11.3) with ESMTP id 31NKGXer013066; Thu, 23 Feb 2023 12:16:33 -0800 (envelope-from sjg@juniper.net) Received: by kaos.jnpr.net (Postfix, from userid 1377) id 6574020FB9; Thu, 23 Feb 2023 12:15:34 -0800 (PST) Received: from kaos.jnpr.net (localhost [127.0.0.1]) by kaos.jnpr.net (Postfix) with ESMTP id 645A921181; Thu, 23 Feb 2023 12:15:34 -0800 (PST) To: Mark Millard CC: Bryan Drewery , Current FreeBSD , Peter , Subject: Re: FYI: Why META_MODE rebuilds so much for building again after installworld (no source changes) In-Reply-To: <242BB478-B2FE-4BCC-A56E-098F3FEB3EE1@yahoo.com> References: <3345EBA5-A09C-4E3F-B94D-39F57F56BDBB@yahoo.com> <73088.1611797582@kaos.jnpr.net> <10819.1677108389@kaos.jnpr.net> <76FA98EF-6184-4D7E-A01F-0EE8117D0D10@yahoo.com> <29887.1677115125@kaos.jnpr.net> <27790339-240F-4C97-97C7-38AFD8DE03D5@yahoo.com> <7FB6F619-6E71-4075-8A6C-573564371DD5@yahoo.com> <2655.1677134606@kaos.jnpr.net> <242BB478-B2FE-4BCC-A56E-098F3FEB3EE1@yahoo.com> Comments: In-reply-to: Mark Millard message dated "Wed, 22 Feb 2023 23:10:49 -0800." From: "Simon J. Gerraty" X-Mailer: MH-E 8.6+git; nmh 1.7.1; GNU Emacs 28.1 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 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <40100.1677183334.1@kaos.jnpr.net> Content-Transfer-Encoding: quoted-printable Date: Thu, 23 Feb 2023 12:15:34 -0800 Message-ID: <42586.1677183334@kaos.jnpr.net> X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: MW2NAM12FT087:EE_|DS0PR05MB9719:EE_ X-MS-Office365-Filtering-Correlation-Id: 3398aa5d-7df7-4db0-a813-08db15dadc50 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: pSn142pQn6K6nAV9IN+NILKB8FAkZjhBWmaz0XwJvIjsdU1SJs/vhJsq2ALCqzmlcPs9FsqToU84m3Dj+9YYvB93Ol8UHAUwiXbd1Wqwzsl7+Biuu6EEZnKjaehuoUntkMN6iVnyN1ttouNJ+3PVTkrDgElTTB2E2bn0L1BtHfzKdFTPA5Du4RoSzCJrxK7deHMTaPqw+v4742HXUUuEsuTIZ8muBS0qoIO0yka1VeGUlv4GjCqjqkYYNMumHsGrl2HHodpMDdgtaCUr5CrwFe10pmEUxxdG9WMPDyV5VGju0D9Q72KTBmImGh5Wb3qnOFiAO/IAgb/LcrknWQr926gcOiS+ICk+f6llYdmysq/NDjmaRMDYmSUwXdHu7ZkAwtrYwas5eSrYDrfniM1Kzmah42lHO0qlOm/S4H17XtdkuwP1JmVuWI0wHxEVlh30h5ZeZJt3EeNOD8dhGDMxutQVCMsrIWtEJWmnhGF6c2rwnBzNe6iZ8WPtERz9JppBobgtyrVj9n7IAD0+GiEEDM1gk1tE+kZKsRI/tQyu2zbU/53MA78xnfQ0l39rhb7g1n4NKHaXyu2CxzjpshIhUINmwABe659+F5eZpEUuVq5Pm5LT6z/iCBluiE9UbYMsv0NKbeTmKvgkYfCdT9rCs+1p0XD8szMOxPFQmBRmHJlwrsL9IqBg/yAGEU//AKm5ECunDQentBZ2QtQeT1qwwN9d7NYQ4HYmSnO/r7i8cKtBEcZGwG/BaJ66Fs1OFqCoxv3mL+G8tnfRwkECHtb3mQ== X-Forefront-Antispam-Report: CIP:66.129.239.14;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:p-exchfe-eqx-01.jnpr.net;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230025)(4636009)(39860400002)(376002)(396003)(346002)(136003)(451199018)(36840700001)(46966006)(40470700004)(7696005)(356005)(316002)(86362001)(54906003)(70206006)(4326008)(70586007)(26005)(186003)(6266002)(6916009)(66899018)(82310400005)(8676002)(478600001)(41300700001)(9686003)(55016003)(40460700003)(5660300002)(8936002)(107886003)(82740400003)(47076005)(36860700001)(2906002)(7126003)(81166007)(336012)(40480700001)(36900700001);DIR:OUT;SFP:1102; X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Feb 2023 20:16:34.5915 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 3398aa5d-7df7-4db0-a813-08db15dadc50 X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4;Ip=[66.129.239.14];Helo=[p-exchfe-eqx-01.jnpr.net] X-MS-Exchange-CrossTenant-AuthSource: MW2NAM12FT087.eop-nam12.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS0PR05MB9719 X-Proofpoint-ORIG-GUID: LwrSzAMhxMQbZ8TuxXXZzNYoM1ZUlBqA X-Proofpoint-GUID: LwrSzAMhxMQbZ8TuxXXZzNYoM1ZUlBqA X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.219,Aquarius:18.0.930,Hydra:6.0.562,FMLib:17.11.170.22 definitions=2023-02-23_13,2023-02-23_01,2023-02-09_01 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 spamscore=0 malwarescore=0 mlxlogscore=493 impostorscore=0 mlxscore=0 adultscore=0 priorityscore=1501 suspectscore=0 lowpriorityscore=0 clxscore=1015 phishscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2212070000 definitions=main-2302230168 X-Rspamd-Queue-Id: 4PN47K4FGDz4KXZ X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:26211, ipnet:208.84.65.0/24, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N Mark Millard wrote: > The contribution to the list is currently generated via > use of: > = > .if ${.MAKE.LEVEL} =3D=3D 0 Why is this guarded by .MAKE.LEVEL 0? .MAKE.META.IGNORE_* should be largely irrelevant at level 0 which in the DIRDEPS_BUILD is reserved for orchestration. Even in the legacy build, level 0 would be just the top-level makefiles and anything dealing with meta files would be expected to be level 1 or greater. = > .for ignore_legacy_tool in awk cap_mkdb cat cp crunchgen crunchide dd eg= rep env file2c gencat grep gzip jot lex lb ln m4 mkcsmapper mktemp mv patc= h realpath rm sed sh touch truncate uudecode uuencode xargs > .MAKE.META.IGNORE_PATHS+=3D ${MAKEOBJDIR}/tmp/legacy/usr/sbin/${ignore_l= egacy_tool} > .endfor > .for ignore_other_tool in ctfconvert objcopy nm > .MAKE.META.IGNORE_PATHS+=3D ${MAKEOBJDIR}/tmp/usr/bin/${ignore_other_too= l} > .endfor > .MAKE.META.IGNORE_PATHS:=3D ${.MAKE.META.IGNORE_PATHS} > .endif > = > The :=3D use is how I avoided needing to worry about late binding > substitutions for my additions (independent of the internals of > make's specific .MAKE.META.IGNORE_PATHS handling). Depending on value of MAKEOBJDIR the above may not work at all. The default is share/mk/src.sys.obj.mk:_default_makeobjdir=3D $${.CURDIR:S,^$${SRCTOP},$$= {OBJTOP},} In which case the above would not be correct. > For reference: > = > # more ~/sys-build-scripts.amd64-host/make-main-amd64-nodbg-clang.amd64-= host.sh > kldload -n filemon && \ > cd /usr/main-src/ && \ > mkdir -p /usr/obj/BUILDs/main-amd64-nodbg-clang/sys-typescripts/ && \ > script /usr/obj/BUILDs/main-amd64-nodbg-clang/sys-typescripts/typescript= -make-amd64-nodbg-clang-amd64-host-$(date +%Y-%m-%d:%H:%M:%S) \ > env __MAKE_CONF=3D"/usr/home/root/src.configs/make.conf" SRCCONF=3D"/dev= /null" SRC_ENV_CONF=3D"/usr/home/root/src.configs/src.conf.amd64-nodbg-cla= ng.amd64-host" \ > WITH_META_MODE=3Dyes \ > MAKEOBJDIRPREFIX=3D"/usr/obj/BUILDs/main-amd64-nodbg-clang" \ > make $* > = > = > =3D=3D=3D > Mark Millard > marklmi at yahoo.com From nobody Thu Feb 23 20:23:02 2023 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 4PN4Gg62QSz3sjKv for ; Thu, 23 Feb 2023 20:23:23 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic313-20.consmr.mail.gq1.yahoo.com (sonic313-20.consmr.mail.gq1.yahoo.com [98.137.65.83]) (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 4PN4Gf3qjMz4LnB for ; Thu, 23 Feb 2023 20:23:22 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=DLkWpTQI; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.83 as permitted sender) smtp.mailfrom=marklmi@yahoo.com; dmarc=pass (policy=reject) header.from=yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1677183800; bh=rBnguEV2SrfS/hPvkNE9wl+XV0JSkNCu55cAXP1Qw6o=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=DLkWpTQIEOyiSMY6FvK21G1JIcfUBPYgqiM0038MmgZr2PfDAXkcQqHTh4nf5binnQYFJFSSHUuwG1ZuNUVpTWmyxm6h4uZ6EpEQPP8kM/Y6meMHrDRZDA3I87bxeGa3NvsLz+agAvZ2hGuM0rKuGFmoe/U+F3fnNZxI+Sd+0nIP2786Kx8MzVbvk7o71vVF66sdGYd9GWWhyd6S++jhA7dRh78eHMTa5ii8ggb7jtVwX6wn5gAQgrztUDJc95ob2y8BjAd1EZuDgrmZBvLY6zWiCdesEaWWNxEus8He/NRtLlbEbtW9rtnKAz0B4FzJekSYrX+wy8+W89yl9GxN6A== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1677183800; bh=KSnBRjHIEUxsRsGl8z49Mfi6eBlYGO35lOJKXXABQhR=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=E4j/vAkenE0224rHsdekPeCYOBgKxGDQilNC65LJCIPL0lVHIB0fWsxn4Jrp+ESlrW8/UiyuuRkYuSgqsbsldc/wr76AOf5MAasKi1fBXJm87qy151G5w+mZ0dp0FxEf5NYlvxmJrkbCk6N976RDcwhNlAN/qTYfTkBpUzAlvrLOlKj8+iSojR/iDd+y8Ir3SAgfRoVy9RpZ92pII7C/t8twiJDvpcjS7BFudVj3lDy57pimRgEgvny/oLL1E6+8tn9lnWrU04bKb5u3Wz9bEFiLTy3RlIHDbEa7rRQzhykqcICfzu3uFdp5E6cjewqBkZhdTkmgh3eJtCTntTjwsg== X-YMail-OSG: tb3CyAYVM1kxel3qJY4EM7LMFRSTr.cJJYkjMkiWSRyXp4RNPxVW3kuhvl_x5cT QMSprd8TkifVjnyk5pi5qdQIdbah61hyq_9eJ7Lrqjv6MfE6bLaCy39JvUIv0Ch_oH.gzzcM4MeO ivUZtfJQL4c4_zMQ30peXIT.vEU.zzngJmp4MOGoOJBVPVPkLCm7MQxSWQL6ozmsHtf32nARdzho buv8LGzjkd0DlHdBkaHgJkXmPa0JFW9vxj8l9XmMc2EH0S5n919Bviv32BW2_Zfc4KNavTAYYrpy vUyKsM5Xi8n7sKqwXk1jqlG58_PyQCgdJsFTguUoH0_k2BJkOHn8doV8Ro4aZD4XiV.hNqDWJGjQ ZPwmFey6AG2q3gjJ5UyKUqoaht.p0jM8NIqACh5LGJfvoqipgHUwq_T0vD3zDwf0MntBn4yXYHzj syDLFB1Mtfvxh4avtuUxKxVsAqh.n99Z0HVJ0UBWP2UVI_s3SoVG.3dg8GJmyDRmKS1GD5bb6cwE GOwyodMLya6exxb3GJesvUmcYxLC8Ik_.Ou98VOu2HfYk_sEMH9y68v_6lPFIpiJaoVM27B4ZIkr 4xXcMC0MSQ6zWrDU2xuJwkA1bK0xDkt6lakrtZIpdsubvCC3J6tM4PNFgtzm2QR19SquueuQOxSc PrtEsbfihZRCJC42QB.P0D0VEPP7pSwb5QbCVEhnqpCpLZR0HTN2mogJM7RgN0jbdULmsfd6OI3I 1foVBFrOz9Uob_iUeu0lSMmMdlqqS4XXm1UU9Z3mglOHQEkeEm8Jal.NUEj6NaO9KoXBx8IdaMy8 0uZa6Imp6pT8_UJDG6Ui8crRYjribahf2tUF6XTfnoTrNN2.YWfpBDjEhX9BfCiMXpXcuuzvTBtP aMKXlb_aS7DzUfHdmDHC4CZkoyluxhISNxYvYppXAsWXkMkd0Dl03Eav3xBHVUP4X3uYQsoa4byb gn.HGQJmZboR6X7FeZeD.GaGvroDBZn_fGpIfVSVvNYRmvgUxjzIHKqsgEMym4YJh76vmwrCbztv kkRJ1sGIZyKRAkIBSe1uD83AUBJNyuBFk4SEJRcDC96t0vjtLOjplNTVUekSvss33IukrIl7WHJn OGKBaPyDknhORAd4TUEHiLGyXSs2jpF8.KHVD5_YLIJQHx7Ni7hR__w61zDlMDbvypk1M9wXd1xR mat_OzWBMYR_myMeb5Wes0wZByXS8BAhFWrN6hG0Uja55R8sMX3uU2s8MXUl2F.w.K6UAvpqY1e0 FKC.TPce3V.SyTa0Z3xo.5fEc5TbrAycWr51JJnzDNpebCcscR2PlM6XEcZklfYmPZoEi6DHVQ6g wMmhA0r5QpQAnwSMAjsRQAJrQNBMYkDgQhF1wnBxO_tKYNUh4TJOq1lyU8fI2OS0NuRprhv1byVn B_QnOfHAe83Dixtxx_JybOXpZAgF9Ac9eFmcouhxHpTrWxlxCxT5vHz58Kl8fatSvfFo8q3nMBwz mM8yfsdqHSgc._Vza_bA2EkAmZqLvWhAcHm6tyNvawjGH9TXmDmn8NVxvd2BcUan6HDDIypjOeEK skh5.3Xz_e.crX4rMkQjU2JqoKB.Ztm7.9xHr.C7hALSypXq.x2FIKsc2Q5W4RVRgCJTgDQ5Q6bA GJwVEoITwtLPyEpY3Rc62nqxOvWHGxA0x4k2u.i6_62_cna89kf.E6ASEpwr9yzMY_Oj7KmzKG2h YzZOZkq63rXlNWAGyJH90rmIeM21A_Y0y4siy1tGG4LNbW8AVUE0u0BKTRGrK1ZjgEmQTPvl98YV I_V2CLoMxDrXPo9DHvhie_P2e2z5vOPXT0tOx92c_ZE5Mmmp9To_hCDohwUQdvuD3tsegj4lXQWR Im0sj8aWEe6HgkwRY7kM.E9jqQ1u_NROQwWVdzaaAaO5Azph0M7wfRtfhyYFUv51CKHr704j3DVz vaWodnlzkGwtLd8s0jxkk6BuHV4WZXunPm94qZdCmrbGtuLCQzSqUVqxEv9SxfS3hi.s8bnlv7Yw Tl3Zn3zzzw2.1xVsQgUFTZjH7ghNIvS.rsmem19jL07pWULdA91Fa6QbfueVWgWTCwLo3v_1qc3K exk92B64xTdm.3JF5nsV4zWnrn9_Hnf0KkrpBXilcdTU9zUA3TaGTqKfpvg0sFUWfHZ5rEyjLhYz 4OVmgd9sEFMcANXl0QChMqbNYqFBrGr0IXX3eXu_LvLFYUoX.dscOaV0CAevlkES9C4yi_Y3U2cG 2kmXiH0oK_sGMEaZ1I3h9PgRJonBowZBVgyp6WjFXyl6hzUSM5Kcsvx9oaGD4Fvwkkn4qsnUi9Av 3he8o X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic313.consmr.mail.gq1.yahoo.com with HTTP; Thu, 23 Feb 2023 20:23:20 +0000 Received: by hermes--production-bf1-57c96c66f6-kqcsw (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 5cee844f486519a9cd19cf1ab6236030; Thu, 23 Feb 2023 20:23:14 +0000 (UTC) Content-Type: text/plain; charset=us-ascii 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 Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.400.51.1.1\)) Subject: Re: FYI: Why META_MODE rebuilds so much for building again after installworld (no source changes) [code level bug evidence] From: Mark Millard In-Reply-To: <266ED18F-9249-46BB-BF96-1D4C5B46FCFC@yahoo.com> Date: Thu, 23 Feb 2023 12:23:02 -0800 Cc: Bryan Drewery , Current FreeBSD , Peter Content-Transfer-Encoding: quoted-printable Message-Id: References: <3345EBA5-A09C-4E3F-B94D-39F57F56BDBB@yahoo.com> <73088.1611797582@kaos.jnpr.net> <10819.1677108389@kaos.jnpr.net> <76FA98EF-6184-4D7E-A01F-0EE8117D0D10@yahoo.com> <29887.1677115125@kaos.jnpr.net> <27790339-240F-4C97-97C7-38AFD8DE03D5@yahoo.com> <72419.1677133429@kaos.jnpr.net> <266ED18F-9249-46BB-BF96-1D4C5B46FCFC@yahoo.com> To: "Simon J. Gerraty" X-Mailer: Apple Mail (2.3731.400.51.1.1) X-Spamd-Result: default: False [-3.46 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.96)[-0.960]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; MV_CASE(0.50)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; MIME_GOOD(-0.10)[text/plain]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RCVD_IN_DNSWL_NONE(0.00)[98.137.65.83:from]; TO_DN_ALL(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; FREEMAIL_FROM(0.00)[yahoo.com]; RCVD_TLS_LAST(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; MIME_TRACE(0.00)[0:+]; FROM_EQ_ENVFROM(0.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; MLMMJ_DEST(0.00)[freebsd-current@FreeBSD.org] X-Rspamd-Queue-Id: 4PN4Gf3qjMz4LnB X-Spamd-Bar: --- X-ThisMailContainsUnwantedMimeParts: N On Feb 23, 2023, at 11:53, Mark Millard wrote: > cached_realpath only reports its "cached_realpath:" notice > (not the purging one) when it does not find the value via > HashTable_FindValue and so does a HashTable_Set : >=20 > const char * > cached_realpath(const char *pathname, char *resolved) > { > const char *rp; >=20 > if (pathname =3D=3D NULL || pathname[0] =3D=3D '\0') > return NULL; >=20 > rp =3D HashTable_FindValue(&cached_realpaths, pathname); > if (rp !=3D NULL) { > /* a hit */ > strncpy(resolved, rp, MAXPATHLEN); > resolved[MAXPATHLEN - 1] =3D '\0'; > return resolved; > } >=20 > rp =3D realpath(pathname, resolved); > if (rp !=3D NULL) { > HashTable_Set(&cached_realpaths, pathname, = bmake_strdup(rp)); > DEBUG2(DIR, "cached_realpath: %s -> %s\n", pathname, = rp); > return resolved; > } >=20 > /* should we negative-cache? */ > return NULL; > } >=20 > cached_realpaths is global: >=20 > static HashTable cached_realpaths; >=20 > So with -ddM why do I see lots of "cached_realpath:" > notices for the same path? For example: >=20 > # grep "tmp/legacy/usr/sbin/ln\>" = /usr/obj/BUILDs/main-amd64-nodbg-clang/sys-typescripts/typescript-make-amd= 64-nodbg-clang-amd64-host-2023-02-23:10:20:26 | more > cached_realpath: = /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/tmp/legacy= /usr/sbin/ln -> = /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/tmp/legacy= /bin/ln > cached_realpath: = /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/tmp/legacy= /usr/sbin/ln -> = /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/tmp/legacy= /bin/ln > Caching 02:49:37 Feb 23, 2023 for = /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/tmp/legacy= /usr/sbin/ln > = /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/usr.bin/aw= k/awkgram.tab.h.meta: 22: file = '/usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/tmp/legac= y/usr/sbin/ln' is newer than the target... > cached_realpath: = /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/tmp/legacy= /usr/sbin/ln -> = /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/tmp/legacy= /bin/ln > Caching 02:49:37 Feb 23, 2023 for = /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/tmp/legacy= /usr/sbin/ln > cached_realpath: = /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/tmp/legacy= /usr/sbin/ln -> = /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/tmp/legacy= /bin/ln > Caching 02:49:37 Feb 23, 2023 for = /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/tmp/legacy= /usr/sbin/ln > cached_realpath: = /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/tmp/legacy= /usr/sbin/ln -> = /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/tmp/legacy= /bin/ln > Caching 02:49:37 Feb 23, 2023 for = /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/tmp/legacy= /usr/sbin/ln > cached_realpath: = /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/tmp/legacy= /usr/sbin/ln -> = /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/tmp/legacy= /bin/ln > Caching 02:49:37 Feb 23, 2023 for = /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/tmp/legacy= /usr/sbin/ln > cached_realpath: = /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/tmp/legacy= /usr/sbin/ln -> = /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/tmp/legacy= /bin/ln > Caching 02:49:37 Feb 23, 2023 for = /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/tmp/legacy= /usr/sbin/ln > = /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/usr.bin/aw= k/awkgram.tab.h.meta: 22: file = '/usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/tmp/legac= y/usr/sbin/ln' is newer than the target... > . . . >=20 > A possible cause is something I ran into while looking around: >=20 > /* A read-only range of a character array, NOT null-terminated. */ > typedef struct Substring { > const char *start; > const char *end; > } Substring; > . . . > MAKE_STATIC Substring > Substring_Init(const char *start, const char *end) > { > Substring sub; >=20 > sub.start =3D start; > sub.end =3D end; > return sub; > } > . . . > /* Find the entry corresponding to the key, or return NULL. */ > HashEntry * > HashTable_FindEntry(HashTable *t, const char *key) > { > const char *keyEnd; > unsigned int h =3D Hash_String(key, &keyEnd); > return HashTable_Find(t, Substring_Init(key, keyEnd), h); > } > . . . > /* A read-only range of a character array, NOT null-terminated. */ > typedef struct Substring { > const char *start; > const char *end; > } Substring; > . . . > MAKE_STATIC Substring > Substring_Init(const char *start, const char *end) > { > Substring sub; >=20 > sub.start =3D start; > sub.end =3D end; > return sub; > } > . . . > /* Find the entry corresponding to the key, or return NULL. */ > HashEntry * > HashTable_FindEntry(HashTable *t, const char *key) > { > const char *keyEnd; > unsigned int h =3D Hash_String(key, &keyEnd); > return HashTable_Find(t, Substring_Init(key, keyEnd), h); > } > . . . > /* This hash function matches Gosling's Emacs and java.lang.String. */ > static unsigned int > Hash_String(const char *key, const char **out_keyEnd) > { > unsigned int h; > const char *p; >=20 > h =3D 0; > for (p =3D key; *p !=3D '\0'; p++) > h =3D 31 * h + (unsigned char)*p; >=20 > *out_keyEnd =3D p; > return h; > } >=20 > But after the loop: *p=3D=3D'\0' so *out_keyEnd=3D=3D'\0' > and the FindEntry Substring_Init(key, keyEnd) ends > up including the '\0' byte. >=20 > But note that the h in Hash_String did not include the > '\0' byte. Call this h value h_VALUE0 for later reference. > Then look at: >=20 > /* This hash function matches Gosling's Emacs and java.lang.String. */ > unsigned int > Hash_Substring(Substring key) > { > unsigned int h; > const char *p; >=20 > h =3D 0; > for (p =3D key.start; p !=3D key.end; p++) > h =3D 31 * h + (unsigned char)*p; > return h; > } >=20 > This h does include the '\0' byte so h=3D=3D(unsigned = int)(31*h_VALUE0). Dumb mistake on my part. Actually *(key.end) is never used., even if *(key.end) !=3D '\0' . > I expect the mismatched hash values explain the repeated > "cached_realpath:" notices for the same path: inserted > but never found. Still, the comments and code do not match and I've not checked all usage for assumptions about *(key.end) vs. '\0' . =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Thu Feb 23 20:25:03 2023 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 4PN4LC6dPGz3sjrZ for ; Thu, 23 Feb 2023 20:26:27 +0000 (UTC) (envelope-from sjg@juniper.net) Received: from mx0a-00273201.pphosted.com (mx0a-00273201.pphosted.com [208.84.65.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.pphosted.com", Issuer "Thawte RSA CA 2018" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4PN4LC5Ltjz4Mn4; Thu, 23 Feb 2023 20:26:27 +0000 (UTC) (envelope-from sjg@juniper.net) Authentication-Results: mx1.freebsd.org; none Received: from pps.filterd (m0108156.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 31NBt98m006042; Thu, 23 Feb 2023 12:26:06 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=to : cc : subject : in-reply-to : references : from : mime-version : content-type : content-id : content-transfer-encoding : date : message-id; s=PPS1017; bh=zOhYNp0S09uoEra7w6m81jlDweaERvlIpUILMC/jQHk=; b=QJyIvV2mTJI3nDyRyWgKpqs+uYTSFvWNi/xBMC4/lAPw6YyHRRhHviODJ80X8G3KOR2a S15p7iD0JVYYzMq4DWl9ZfCaT4yaITx47fsBGz1zpJfZxJ3OAuQPaNfjIiSNfvucQIC5 swl+KGjSrC9PVtHoqarIb8AQ9CxeC8E2IAcUOthl9bjW6PbcOeqrsshxNnkqjKfzeosb j15bawvvlhYU2uYHZjLa3XwEP2Nv5hng3H4bCsRBW1ucpwoB0R7kbZQ9aAld/GlJR7Tb zZvuhg1Zmi/gBBAr1E1DaAE5MP+ZEUxnYkET95X33foTMuHxyRbQG6DcYHoOUsFZ7sfz OA== Received: from dm4pr02cu001-vft-obe.outbound.protection.outlook.com (mail-centralusazlp17012028.outbound.protection.outlook.com [40.93.13.28]) by mx0a-00273201.pphosted.com (PPS) with ESMTPS id 3nwyb99mc6-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 23 Feb 2023 12:26:06 -0800 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=El1GUp3vRq+mR8oJm8s6eKjMkllcabb1+h2/39h6oAw0G9UiXM3lTZkgCJT5c5CNOtDvvyibOoqLtJIO7GEKYZw6wO5kQVYbNRKypzv3hc2Pu6h81XTU7fQ/LNsA/9aP+DPnu50oMz2uOcjsZANeEfm0sLn2vHxqWZsf/hd0lMDpGqyo89lzpl92QQNcRSd1iGqt4yGnj4x6wfxZ4SlNKJWseFd0i+Chzou2KZFmNdxhgq748mMk/4Ol3wDLDpWNRSlwwhS68kjv4SbipY0eFzuWakFa4vlm7FTgXA82+zAhntG9vz7enSDLi5fj6K117WNpwX2RBkGltCX9vwS0Ng== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=zOhYNp0S09uoEra7w6m81jlDweaERvlIpUILMC/jQHk=; b=cFmZR2ZuIqHE+BkcFD9d569Jx8jd108uPXwH9fTHFa6op3Pdqcr1cd3yHIjSyKFawhj/pzhY3mv3CMH/W/nIcP21cVnIg/NORlLWBldf2XH/YtM86/J6yZ8eDjfroXM+Qx87DSPny8+dusiUXCtGbFh5tLB+zeo2DMz8yMJI41gMAR2O/JstPO4fS8MJWoV2f72F3RuKLXPni8Jac3oCKw8sMhU5RTcqbEEW9xnNdz2QDosbKyNouR5iVCA40cWy9illpI4PcZTHtFBz6jPUaAhei0di2rtlUWSmJmOS2Rp72WFdjim8BoOoEWlhLrVEHFmc7hteaEzOFzxfqrHg9g== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=softfail (sender ip is 66.129.239.15) smtp.rcpttodomain=yahoo.com smtp.mailfrom=juniper.net; dmarc=fail (p=reject sp=reject pct=100) action=oreject header.from=juniper.net; dkim=none (message not signed); arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=zOhYNp0S09uoEra7w6m81jlDweaERvlIpUILMC/jQHk=; b=M6o2DcuJm4HRF0JGp1J4sqd3Llw3cnnoxHl9fG0Mvws1uOzgquwcprwPtHVihfkBaooG0LQpKl8R0kKWcItWJa4A/8T3II9KfFf2/zoPzbGfMuOcd/tF4Z9DKUSPc8zSq92oAkWaIAjWcDf1hNcsc2Ah9n0C/0aHBm4IIXqCZPU= Received: from MW4PR03CA0014.namprd03.prod.outlook.com (2603:10b6:303:8f::19) by SN6PR05MB5950.namprd05.prod.outlook.com (2603:10b6:805:fb::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6111.19; Thu, 23 Feb 2023 20:26:04 +0000 Received: from MW2NAM12FT065.eop-nam12.prod.protection.outlook.com (2603:10b6:303:8f:cafe::9c) by MW4PR03CA0014.outlook.office365.com (2603:10b6:303:8f::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6134.21 via Frontend Transport; Thu, 23 Feb 2023 20:26:03 +0000 X-MS-Exchange-Authentication-Results: spf=softfail (sender IP is 66.129.239.15) smtp.mailfrom=juniper.net; dkim=none (message not signed) header.d=none;dmarc=fail action=oreject header.from=juniper.net; Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.15 as permitted sender) Received: from p-exchfe-eqx-02.jnpr.net (66.129.239.15) by MW2NAM12FT065.mail.protection.outlook.com (10.13.180.181) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6156.7 via Frontend Transport; Thu, 23 Feb 2023 20:26:03 +0000 Received: from p-exchbe-eqx-01.jnpr.net (10.104.9.14) by p-exchfe-eqx-02.jnpr.net (10.104.9.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.30; Thu, 23 Feb 2023 14:26:03 -0600 Received: from p-mailhub01.juniper.net (10.104.20.6) by p-exchbe-eqx-01.jnpr.net (10.104.9.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.30 via Frontend Transport; Thu, 23 Feb 2023 14:26:03 -0600 Received: from kaos.jnpr.net (kaos.jnpr.net [172.23.255.201]) by p-mailhub01.juniper.net (8.14.4/8.11.3) with ESMTP id 31NKQ2WW015535; Thu, 23 Feb 2023 12:26:02 -0800 (envelope-from sjg@juniper.net) Received: by kaos.jnpr.net (Postfix, from userid 1377) id 98F7820E6B; Thu, 23 Feb 2023 12:25:03 -0800 (PST) Received: from kaos.jnpr.net (localhost [127.0.0.1]) by kaos.jnpr.net (Postfix) with ESMTP id 9879D20EE9; Thu, 23 Feb 2023 12:25:03 -0800 (PST) To: Mark Millard CC: Bryan Drewery , Current FreeBSD , Peter , Subject: Re: FYI: Why META_MODE rebuilds so much for building again after installworld (no source changes) In-Reply-To: References: <3345EBA5-A09C-4E3F-B94D-39F57F56BDBB@yahoo.com> <73088.1611797582@kaos.jnpr.net> <10819.1677108389@kaos.jnpr.net> <76FA98EF-6184-4D7E-A01F-0EE8117D0D10@yahoo.com> <29887.1677115125@kaos.jnpr.net> <27790339-240F-4C97-97C7-38AFD8DE03D5@yahoo.com> <72419.1677133429@kaos.jnpr.net> Comments: In-reply-to: Mark Millard message dated "Thu, 23 Feb 2023 00:07:54 -0800." From: "Simon J. Gerraty" X-Mailer: MH-E 8.6+git; nmh 1.7.1; GNU Emacs 28.1 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 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <97974.1677183903.1@kaos.jnpr.net> Content-Transfer-Encoding: quoted-printable Date: Thu, 23 Feb 2023 12:25:03 -0800 Message-ID: <30.1677183903@kaos.jnpr.net> X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: MW2NAM12FT065:EE_|SN6PR05MB5950:EE_ X-MS-Office365-Filtering-Correlation-Id: bc20adc2-36c3-4259-46a6-08db15dc2f98 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: mQiHWCLdGBa7XwKHqn6gR4MjVBTQ37MqHHAHxt4tjkMqaYpYdnDPNB5NKX9xvQ8K44WUmvhK+MLZDot+xFbAxVuSEcTqAUMjtSjXncQEFOrMDBEEGJZFSG7dT4CIvyrh6ao6MoIM+DuxXR8czmqc+kKfk6Oug5XobhImzuepQ5bq3PDBAHKxf8pcmhyc5IYe9cdMvw9j8FSLQZPhRisej0hJHKv5thfEPwRk2ceTZtaTk49zqvMPO4fgEvQ9y8C+RD1LZNwsd9B8rWlDW+lBtEkxGmiXATd3MBTguSB7vHh1rVvEIToc1I2ThAJrwMA+z96s4nPW8acnpr0VmZ12OksRVohrPv6PGrQSa57EyBUokQcGUyfXnemMK/BpM0s0eAaA8FPb0x8d7DeZd2GbrzcikPHwA89rnOgwp+Wl0J12nuUkjjqm/XBLZv8Ux7NFAYiyZNKhHLyb0+kbpQvW4VpvDqiJl2k4hgcjshCFpBPRY8FR7OV39Z9zk8zC0abGdckWs3DybaF/7vjP0DAoXcu5lnQT9MjGzlkGz2CxYAcT61SC97N6EXIJfxp8vor22anIKvBtWw7/6nK4Sv7A2SNrPwHsxeiDJQXHtmIy9odN9fSBxnEVOABIeoTZMJztNfPwZzQQXI+pnR2P1eIK1eHFnLDbvamO98TMvam95z9Cz9DAmsj51tTXurpCdY2Q3D6m8seagogJW5+nq5dH+fiXbbI/5JHDCXFFvgXFig4= X-Forefront-Antispam-Report: CIP:66.129.239.15;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:p-exchfe-eqx-02.jnpr.net;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230025)(4636009)(39860400002)(136003)(376002)(346002)(396003)(451199018)(40470700004)(36840700001)(46966006)(4326008)(336012)(70586007)(316002)(8676002)(40460700003)(7696005)(54906003)(41300700001)(356005)(8936002)(70206006)(6916009)(55016003)(86362001)(5660300002)(478600001)(82310400005)(6266002)(186003)(26005)(107886003)(9686003)(47076005)(7126003)(40480700001)(2906002)(82740400003)(81166007)(83380400001)(36860700001)(36900700001);DIR:OUT;SFP:1102; X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Feb 2023 20:26:03.7148 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: bc20adc2-36c3-4259-46a6-08db15dc2f98 X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4;Ip=[66.129.239.15];Helo=[p-exchfe-eqx-02.jnpr.net] X-MS-Exchange-CrossTenant-AuthSource: MW2NAM12FT065.eop-nam12.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR05MB5950 X-Proofpoint-ORIG-GUID: eOBP4ChjHLSAoaaqYEzY6BibafU8p9pq X-Proofpoint-GUID: eOBP4ChjHLSAoaaqYEzY6BibafU8p9pq X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.219,Aquarius:18.0.930,Hydra:6.0.562,FMLib:17.11.170.22 definitions=2023-02-23_13,2023-02-23_01,2023-02-09_01 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 spamscore=0 malwarescore=0 mlxlogscore=999 impostorscore=0 mlxscore=0 adultscore=0 priorityscore=1501 suspectscore=0 lowpriorityscore=0 clxscore=1015 phishscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2212070000 definitions=main-2302230169 X-Rspamd-Queue-Id: 4PN4LC5Ltjz4Mn4 X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:26211, ipnet:208.84.65.0/24, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N Mark Millard wrote: > >> Also, OBJTOP is not constant over all the parts of > >> buildworld buildkernel . Having the late-substitution > >> form of notation ${OBJTOP} might not be appropriate > >> for the content of .MAKE.META.IGNORE_PATHS . > > > > Fwiw .MAKE.META.IGNORE_PATHS is evaluated when meta_init() is > > called after all the makefiles have been read - and had a > > chance to influence .MAKE.MODE, so I'm not sure how varaiablity of > > OBJTOP would matter? > = > To my knowledge, there is no place to find documentation > about when/how-often the .MAKE.META.IGNORE_PATHS original > text is reevaluated other than the above statement or > source code inspection. (Others have a similar status.) True. That should be fixed. .MAKE.META.IGNORE_PATHS is only evaluated once by make after all makefiles have been read. It is use to populate a list. By contrast .MAKE.META.IGNORE_PATTERNS and .MAKE.META.IGNORE_FILTER are evaluated for every line of filemon output - but again all that happens after all makefiles have been read. > -dV -V.MAKE.META.IGNORE_PATHS use does list ${__MAKE_SHELL} > but lists /bin/sh without the -dV . (So -V use does not > give a direct clue at what you report.) One of the local changes to bmake in FreeBSD is that = without -dV -V shows the fully resolved value. > I got past the issue using :=3D before reading the above. > (I'm also using MAKEOBJDIR instead of OBJTOP currently.) Per my last response, I'd be pretty sure MAKEOBJDIR is incorrect. > = > >>> .MAKE.META.IGNORE_PATHS+=3D ${OBJTOP}/tmp/ > >> > >> (Ignoring the variability of OBJTOP issue . . .) > >> > >> I do not expect that would work: ignoring things > >> it likely should not. > > > > Sure, but it may be useful as an experiment to ensure things are > > behaving as expected. > = > As a test: > = > .if ${.MAKE.LEVEL} =3D=3D 0 > .MAKE.META.IGNORE_PATHS+=3D ${MAKEOBJDIR:tA}/tmp/ > .MAKE.META.IGNORE_PATHS:=3D ${.MAKE.META.IGNORE_PATHS} > .endif Lose the .if ${.MAKE.LEVEL} =3D=3D 0 it is almost certainly keeping things from working as expected. > I still get things like: > = > /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/sys/GENE= RIC-NODBG/modules/usr/main-src/sys/modules/zlib/x86.meta: 23: file '/usr/o= bj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/tmp/legacy/usr/s= bin/realpath' is newer than the target... > Building /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64= /sys/GENERIC-NODBG/modules/usr/main-src/sys/modules/zlib/x86 Because that will not be level 0 and so .MAKE.META.IGNORE_PATHS is not set. > = > and: > = > /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/sys/GENE= RIC-NODBG/modules/usr/main-src/sys/modules/xl/opt_platform.h.meta: 12: fil= e '/usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/tmp/leg= acy/usr/sbin/ln' is newer than the target... > Building /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64= /sys/GENERIC-NODBG/modules/usr/main-src/sys/modules/xl/opt_platform.h > = > for both of a pair of back-to-back runs of buildworld buildkernel. > = > FYI: The file system is zfs with mounts that look > like: > = > zoptb /zoptb > zoptb/BUILDs /usr/obj/BUILDs > . . . > zoptb/BUILDs/main-amd64-nodbg-clang /usr/obj/BUILDs/main-amd64-nodbg-cl= ang > . . . > zoptb/ROOT/main-amd64 / > . . . > zoptb/tmp /tmp > . . . > = > # bectl list > BE Active Mountpoint Space Created > 13S-amd64 - - 4.97G 2021-08-20 16:57 > 13_0R-amd64 - - 4.30G 2021-08-20 16:56 > 13_1R-amd64 - - 4.12G 2022-03-10 12:38 > main-amd64 NR / 7.42G 2023-02-19 15:37 > old-main-amd64 - - 2.25G 2023-02-09 19:07 > = > (I use zfs in order to use bectl on a couple of > systems, not for redundancy.) > = > = > >> Also, I'd rather grow a smaller set of ignores > >> gradually to make it easier to detect if an > >> addition starts causing a problem and can be > >> backed out. Starting with everything ignored > >> would make things much harder to figure out > >> when ignoring creates a problem. > > > > Yes. > > > >> > >>> You might need ${OBJTOP:tA}/tmp/ > >>> or both. > > > > I found it necessary in the unit tests to add :tA to both TMPDIR > > and .OBJDIR to get sane result on one test platform. > > > >>>> It is using paths that match the -dM output lines ( sbin > >>>> use despite sbin -> ../bin being a symbolic link). > > > > use :tA if you want to ensure consistent results. > = > So, for each: > = > .MAKE.META.IGNORE_PATHS+=3D ${MAKEOBJDIR}/tmp/legacy/usr/sbin/${ignore_l= egacy_tool} > = > I need to form an overall :tA on the path? Something > like: > = > .if ${.MAKE.LEVEL} =3D=3D 0 I think you need to first get rid of that level 0 check before worrying about anything else. > .for ignore_legacy_tool in awk cap_mkdb cat cp crunchgen crunchide dd eg= rep env file2c gencat grep gzip jot lex lb ln m4 mkcsmapper mktemp mv patc= h realpath rm sed sh touch truncate uudecode uuencode > xargs > IGNORELEGACY_${ignore_legacy_tool}=3D ${MAKEOBJDIR}/tmp/legacy/usr/sbin/= ${ignore_legacy_tool} > .MAKE.META.IGNORE_PATHS+=3D ${IGNORELEGACY_${ignore_legacy_tool}:tA} > .endfor > .for ignore_other_tool in ctfconvert objcopy nm > IGNOREOTHER_${ignore_other_tool}=3D ${MAKEOBJDIR}/tmp/usr/bin/${ignore_o= ther_tool} > .MAKE.META.IGNORE_PATHS+=3D ${IGNOREOTHER_${ignore_other_tool}:tA} > .endfor > .MAKE.META.IGNORE_PATHS:=3D ${.MAKE.META.IGNORE_PATHS} > .endif > = > Such seems to make no difference to the text reported via > -dV -V.MAKE.META.IGNORE_PATHS in my context. Yes, right now I think your main problem is only setting .MAKE.META.IGNORE_PATHS at level 0 From nobody Thu Feb 23 20:28:35 2023 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 4PN4QJ5GjCz3sjln for ; Thu, 23 Feb 2023 20:30:00 +0000 (UTC) (envelope-from sjg@juniper.net) Received: from mx0b-00273201.pphosted.com (mx0b-00273201.pphosted.com [67.231.152.164]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.pphosted.com", Issuer "Thawte RSA CA 2018" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4PN4QJ3LvBz4QCn; Thu, 23 Feb 2023 20:30:00 +0000 (UTC) (envelope-from sjg@juniper.net) Authentication-Results: mx1.freebsd.org; none Received: from pps.filterd (m0108162.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 31NIWI79013834; Thu, 23 Feb 2023 12:29:39 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=to : cc : subject : in-reply-to : references : from : mime-version : content-type : content-id : content-transfer-encoding : date : message-id; s=PPS1017; bh=PzLIlLdaHWswmxItJQ6xIL+jlk4rcskxM7fX5LtfJr4=; b=ktfDe0RSE8tJMQbxvbJ5j9bJmaoiA6oVpub6zX5iy7EENanFGjMfMuzvQFbnodfND/5g sjp5w+RboBcTCCUyHW3qfeJoAz7Ubvdive2RdhR1HZ/8P8SGOIKB7S2LHSg/33NErMQL Rao70uLUaND5fj+7OOUmmZWsq3pk3Lmc/GdeI+fFBdVkFAIUY+WdYmEOsBA3BSgkN1nY Dr8Np6Zh5ZhdZiE5yOGggh0yzLOZMpAEhC7UVc+fA8Vln0UedmeqaTSeTPFT51cHQRvC wdYr4GvaNoOG/JWQ0cZR8sQmRIcOKp2GP8+9fhEtrp4ux/lBxpdReLjXzJKuju3kJ4e4 aQ== Received: from co1pr02cu002-vft-obe.outbound.protection.outlook.com (mail-westus2azlp17010009.outbound.protection.outlook.com [40.93.10.9]) by mx0b-00273201.pphosted.com (PPS) with ESMTPS id 3nwy85a6f9-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 23 Feb 2023 12:29:38 -0800 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=AJZanvT+adSThpbVrpuMDnxpYQpaqUfMr8Lll50TIXCPoTWdYFUu+JzC3sNwqhVoeT7QGaUVOEr3P4XK4gAeuMagjlHmXGvByI9LW/TKMe0ZKI9qbblHbDCUbW1GJSH0MGzxLVccio/51+xKZ9w6KeJgIpEJDmrJ0wRqDd6NvwlCeizHfCryteLaXKS8rroH81Q5/DTenXTal3clxJJoYR5gH8zrd2jnw2a5LAeiBlfv94dWv2uoFVnidhGMKsEyinA9anDp5ZwZJ037/Z7j6lXFCZ7qK3TanIErbeX8mZ61KIdKdxQfIZaRvKxtvoDgOR4cfRTa3YHXKN3Ew7KgQQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=PzLIlLdaHWswmxItJQ6xIL+jlk4rcskxM7fX5LtfJr4=; b=HYAWD7eDYy2FTnFLU9pBlQgCoPXPaRnfduJnh2B3twmE+QQH7jTGpE3Y5tgLI7p8x2ucD6bg2GjvJLOMA96Xzteu9ZwvBI8HGHbYohtRQolommUAmAdjrgcR/7ggFvP4iw7KKj+0jri6tehLklOL5V8twIZqDApz41eYErmPKYT8NSlx7WSlkth13m0KetyOwno54Atxj8i3OzsIcj18ONG4qZ8rRc7gSldWVXNDSUaHELgqTRVFeV1T4AnnadlhxWWqoJGXwcLWS20EfuQg84A67D+9Y+OjMnGe/8tzBjbqRILE7B5+IqLR7xLLuPQdBfvkAcpsGAiIPE9skrn8gg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=softfail (sender ip is 66.129.239.14) smtp.rcpttodomain=yahoo.com smtp.mailfrom=juniper.net; dmarc=fail (p=reject sp=reject pct=100) action=oreject header.from=juniper.net; dkim=none (message not signed); arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=PzLIlLdaHWswmxItJQ6xIL+jlk4rcskxM7fX5LtfJr4=; b=kSOe0Xz9zy2Jkch+HUxxpxk3TqPfk2YTt4zwsNCvUH9nOnNdajgbvQ4rV6Xw3gPNM0BWt/GyqkCOqv6HhdR67SzsAg7Ry/6cK05CmrZ74EVBGfyCyBeibZU5p09UwUQYTVvC4qD2JVWTk0ODJHpPF/hhU4hUOTJ7a1eVWDXWKnU= Received: from BN9PR03CA0449.namprd03.prod.outlook.com (2603:10b6:408:113::34) by SN4PR0501MB3792.namprd05.prod.outlook.com (2603:10b6:803:49::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6134.19; Thu, 23 Feb 2023 20:29:36 +0000 Received: from BN8NAM12FT095.eop-nam12.prod.protection.outlook.com (2603:10b6:408:113:cafe::8) by BN9PR03CA0449.outlook.office365.com (2603:10b6:408:113::34) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6134.21 via Frontend Transport; Thu, 23 Feb 2023 20:29:36 +0000 X-MS-Exchange-Authentication-Results: spf=softfail (sender IP is 66.129.239.14) smtp.mailfrom=juniper.net; dkim=none (message not signed) header.d=none;dmarc=fail action=oreject header.from=juniper.net; Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.14 as permitted sender) Received: from p-exchfe-eqx-01.jnpr.net (66.129.239.14) by BN8NAM12FT095.mail.protection.outlook.com (10.13.183.225) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6156.5 via Frontend Transport; Thu, 23 Feb 2023 20:29:36 +0000 Received: from p-exchbe-eqx-02.jnpr.net (10.104.9.15) by p-exchfe-eqx-01.jnpr.net (10.104.9.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.30; Thu, 23 Feb 2023 14:29:35 -0600 Received: from p-exchbe-eqx-01.jnpr.net (10.104.9.14) by p-exchbe-eqx-02.jnpr.net (10.104.9.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.30; Thu, 23 Feb 2023 14:29:35 -0600 Received: from p-mailhub01.juniper.net (10.104.20.6) by p-exchbe-eqx-01.jnpr.net (10.104.9.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.30 via Frontend Transport; Thu, 23 Feb 2023 14:29:35 -0600 Received: from kaos.jnpr.net (kaos.jnpr.net [172.23.255.201]) by p-mailhub01.juniper.net (8.14.4/8.11.3) with ESMTP id 31NKTYoq016241; Thu, 23 Feb 2023 12:29:34 -0800 (envelope-from sjg@juniper.net) Received: by kaos.jnpr.net (Postfix, from userid 1377) id E3A4820F4D; Thu, 23 Feb 2023 12:28:35 -0800 (PST) Received: from kaos.jnpr.net (localhost [127.0.0.1]) by kaos.jnpr.net (Postfix) with ESMTP id DE9CF210A3; Thu, 23 Feb 2023 12:28:35 -0800 (PST) To: Mark Millard CC: Bryan Drewery , Current FreeBSD , Peter , Subject: Re: FYI: Why META_MODE rebuilds so much for building again after installworld (no source changes) [code level bug evidence] In-Reply-To: <266ED18F-9249-46BB-BF96-1D4C5B46FCFC@yahoo.com> References: <3345EBA5-A09C-4E3F-B94D-39F57F56BDBB@yahoo.com> <73088.1611797582@kaos.jnpr.net> <10819.1677108389@kaos.jnpr.net> <76FA98EF-6184-4D7E-A01F-0EE8117D0D10@yahoo.com> <29887.1677115125@kaos.jnpr.net> <27790339-240F-4C97-97C7-38AFD8DE03D5@yahoo.com> <72419.1677133429@kaos.jnpr.net> <266ED18F-9249-46BB-BF96-1D4C5B46FCFC@yahoo.com> Comments: In-reply-to: Mark Millard message dated "Thu, 23 Feb 2023 11:53:49 -0800." From: "Simon J. Gerraty" X-Mailer: MH-E 8.6+git; nmh 1.7.1; GNU Emacs 28.1 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 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <12317.1677184115.1@kaos.jnpr.net> Content-Transfer-Encoding: quoted-printable Date: Thu, 23 Feb 2023 12:28:35 -0800 Message-ID: <12865.1677184115@kaos.jnpr.net> X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BN8NAM12FT095:EE_|SN4PR0501MB3792:EE_ X-MS-Office365-Filtering-Correlation-Id: aac55eb2-6d74-410a-8733-08db15dcae2f X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: 7+CP24YkbCAsiRjKAelXB2LfADxnLFMklFAwNnbF7AcYfMsFk8V8nXeCmX4Gt+A3YZf2rxQoFpxLO7z7idiXqftuiYSK+mzmDOf/mC+bxGm7ITcsGz7ldwoH9daguJb1+MX+IMcEDvg/ymup7QA9gU1HmTAokhzLsqnItIO+sp3iQLpHqYRB9SqKgsIscsmttkLrYddDC+UHh/ShekORHY04nf8vkr7kGyxEEZx3wYBmu6Ah6Twqt+xu/sc/k3sd8aLvjoIZDojQIi2ZMxnbIpE0k7HeDI9FHjvlfzedVHqSG3wiueu7qbDXqKv7f0tnkI0LHDxZRHFZpcdd9cVP4jPiiquluFd4+b8p6W/opjZYtq6tmfvGEYIfMGkkrLRlfmtnpt1Uc0worLu7+jpztnUkOo9rzW7zOQzGpyB7scE4KUNpc2MK/mAc4PCMAIMmej3Sp4gi4WpxMFLNSsKnVHV1Yu17Ja2Rpis8kDY8wB5aPvWb92i3pIYx2jFNbuEw0T5rPxO++iVVhBVoyZs/Cp9Xs6E5QM+hezLkM1UQQc5dGRAUUtO6sR0M1Clz1U6mK6GKjhlok+GShOBxYQjQeamkPilB2GXFOs2kph4/eiG1t+A20fG030vJXCv0/ts/CZdIzkIui59nN0AzSaFx7OJWniRf/uOqzl4LApQSiAJOEzJPPABhGDNjSMrkZUyZun3xs6x+2qFbpB/6f4hbXG5dutrPN+J39bFfkKvewVM= X-Forefront-Antispam-Report: CIP:66.129.239.14;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:p-exchfe-eqx-01.jnpr.net;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230025)(4636009)(396003)(346002)(136003)(376002)(39860400002)(451199018)(40470700004)(36840700001)(46966006)(82310400005)(70206006)(54906003)(47076005)(83380400001)(336012)(316002)(7696005)(107886003)(81166007)(478600001)(5660300002)(41300700001)(6266002)(9686003)(40460700003)(26005)(7126003)(186003)(356005)(40480700001)(86362001)(8936002)(2906002)(55016003)(36860700001)(82740400003)(6916009)(8676002)(70586007)(4326008)(36900700001);DIR:OUT;SFP:1102; X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Feb 2023 20:29:36.0989 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: aac55eb2-6d74-410a-8733-08db15dcae2f X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4;Ip=[66.129.239.14];Helo=[p-exchfe-eqx-01.jnpr.net] X-MS-Exchange-CrossTenant-AuthSource: BN8NAM12FT095.eop-nam12.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN4PR0501MB3792 X-Proofpoint-ORIG-GUID: 6YtDUnGyZ69c3xJmQ_DE0GE7o-yt4ISE X-Proofpoint-GUID: 6YtDUnGyZ69c3xJmQ_DE0GE7o-yt4ISE X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.219,Aquarius:18.0.930,Hydra:6.0.562,FMLib:17.11.170.22 definitions=2023-02-23_13,2023-02-23_01,2023-02-09_01 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 clxscore=1015 impostorscore=0 mlxscore=0 suspectscore=0 malwarescore=0 spamscore=0 bulkscore=0 priorityscore=1501 lowpriorityscore=0 phishscore=0 adultscore=0 mlxlogscore=862 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2212070000 definitions=main-2302230169 X-Rspamd-Queue-Id: 4PN4QJ3LvBz4QCn X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:22843, ipnet:67.231.152.0/24, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N Mark Millard wrote: > So with -ddM why do I see lots of "cached_realpath:" > notices for the same path? For example: how many separate bmake instances are in that log? > = > # grep "tmp/legacy/usr/sbin/ln\>" /usr/obj/BUILDs/main-amd64-nodbg-clang= /sys-typescripts/typescript-make-amd64-nodbg-clang-amd64-host-2023-02-23:1= 0:20:26 | more > cached_realpath: /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd= 64.amd64/tmp/legacy/usr/sbin/ln -> /usr/obj/BUILDs/main-amd64-nodbg-clang/= usr/main-src/amd64.amd64/tmp/legacy/bin/ln > cached_realpath: /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd= 64.amd64/tmp/legacy/usr/sbin/ln -> /usr/obj/BUILDs/main-amd64-nodbg-clang/= usr/main-src/amd64.amd64/tmp/legacy/bin/ln > Caching 02:49:37 Feb 23, 2023 for /usr/obj/BUILDs/main-amd64-nodbg-cl= ang/usr/main-src/amd64.amd64/tmp/legacy/usr/sbin/ln > /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/usr.bin/= awk/awkgram.tab.h.meta: 22: file '/usr/obj/BUILDs/main-amd64-nodbg-clang/u= sr/main-src/amd64.amd64/tmp/legacy/usr/sbin/ln' is newer than the target..= . From nobody Thu Feb 23 21:12:35 2023 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 4PN5Ml575gz3smF0 for ; Thu, 23 Feb 2023 21:12:51 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic314-20.consmr.mail.gq1.yahoo.com (sonic314-20.consmr.mail.gq1.yahoo.com [98.137.69.83]) (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 4PN5Ml2RKlz3Gn7 for ; Thu, 23 Feb 2023 21:12:51 +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=1677186769; bh=sjEkVgQG63dRERCQMSgIOzCHYNfkIZaOGQsPrrxD9eE=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=CPf31CZB0Kvl52korTNWY/K9irn1HUbUZkIcWBtAQM2BvIRVc2PXTBcGgMi6oZnVAc1Kwt41S2DSqkQgozijJAOBXx7nBM58IH/hN7tykQhhdG6VVosDikLOnXIdbsgabmSZKyIDGM3v318AFLvtmRUBO7lxWQjF2jtM1l8UUMQ4/KsZyg/nZNMlBvdQta6hqjx5rQoio0YU4++Qu2XbOMI0TTeAHhNZ2SmUtdmq0Y+BUqnDDGBmkX7lKH14KjwFvbFQRh7j82IAi41Zk6kjUAcHQxRTGxCpJy7Y06t6/ehZ4OsPGPSNtaShlL2oi5PqFfD8FToSUeLm4IN5UY44Yw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1677186769; bh=qTZf5RBvIxXXYIygNV9/A/39jzU1EPTV6ed85dUkjaM=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=e+5UrcH3oR6aGKNgADZcvvSRcVNihqfhYjtTz2hCNe9QAkWyFbEynYDHpsOEtSNSxX39qeVLVaN1WL+nJ5jQCd3duHkCfcOLlH1BQFqJM9R9Fd+oe5B67L6YnlsXVi9fVNr1JzhBzIxdR7s/2NAyRfcmUmVD+h2enTEJIxSPrjnaWNAWhrU4BWLdppLoPxfP/ByT8zzV//mu8zGohCMQ5RrlwgPy4wSZnSgkVXkmcuJ3Qm/WbhBduYmZXtXUpJkHbQBag+lfesL7FAk5WTLhofaEBvf4LAH4nAzpbSjXfPo9M7JmC5n5mxpdFv4WkRFVOPHZ2kWqXUwdNDpQqAU8JQ== X-YMail-OSG: YnWRA30VM1mk4Im2f4V6.5xZk2R5ej4RS4WFpWVbhmgsa5LUgxVUtKm_GRb6RSb V0GqUUNI4RigOsRAbNLoXpyagRmC_HLPBcxX6tcaUU8p_ugiSE5nElqqvQLSFsPVGmwYGzm6Cigb cUc_zR7DH7dLQZqpPwBa_hoYdAGn5oon4cgIdy3HcJoo74gx.VqKfLkXe0rdrKgW.km67JLHpJA8 fv6OTx8APhzu.qw6qQ5XZ8fokANDX.dSrYg9.PYAkaUXSiVB02FrVsROwugQVX6jcssMLDMy3s_2 ki7lBIHQI_Lo6qjwZN0CDrQbYEKkjwrFKdHwFingcSsHgvsR7XboEba7gsbC.JhEJApjDQXA_PBo n4BLgOQqpak7k4_BeN7blXh5IeCMGGH79PqVsneeGAq2Fgj5F.QTTM2Nbay.KJSZhTeM5O3w7.2h WmQV1JUoEyfpdK00.eY2adXcq1GFXEnNLc6m5Ks6TIe1QXCBX0oSyjHsFp26AcFNiFNTXPcvgK_W IZBW3KWKoBR5A9AB.EaX9RFLQpO2vLlqX82ASQru.eYPs0AM0BV5WWeDugdIUg9SRo1NWPinbIDd .bl2UqzPk8aaUr6fo0zqY4d7c18jpCEbahXR4teqFOAZ_OA5HNbJ0HL_cF0Bjh02D.opYFelzdba 8drbAAKMUsjtA9QQ2YSMvTEO_qgSi7GoRlv8BGEzJd1HMfVChmUauA8FxCP.gNUF1gZJFPwcwQE7 QsRc2a3V6j5xtNRVe8xhz2LXx5HKjmZ.ZPqhDpceQ9VPVqYYc8btVTElpR_2Hu3kCnPtwDd4Wd8E 7sFTr7cUoua3riO_N0gRG0ZP8SFSIzGlgH6gN1t7Z4FyvZUMQvGfMg0epARA0cbI4Toe5OH_R.IV uxEUr6nkgOr6Zvv4CV_DwqDFaO5bWHY2vXvkvl1W8K_j_mPjwPZ6VcCXlVyMamLR6i4Bsxu7F_G9 bjqJy29akFoavbPbAwRXLu8UQ6NNTjbcAl42YUN2tlteCRR0MV3EuPgGJyD8XWSIuBRE5wW6WX34 aZ9eBITvWQPEZSY7LgxFSBVoqwsh2c3oRUxsd49OPsSdpkJyn1fLFHude9hNNuIsd70UCQwafNXz J9nFQGnTT7m.NM7Ole3_Fouxs5UAGYMsqzp1fOFVJCmZN4jp8IM1B8edu0.4YPxgP7LNw77VHbEB GQ6zwzffr8u.IrmIBQQ0xW7dbOvrm6fsDblgd9gCYB69a7.4Te2F8ZMViqYjYI_Uj1bZmwt97GYg yTMFFOJ8X14zp4ySJ1UXYOl.z2MUEd934h1H1XDd8JBn5nQtv2fq4eND68eOvEQAapNpNoas5JTd an.T16wUZQJSoQIexAiv9bUOMHZvxjqMzFfO6lnU0TmPgtrU.svUgSyNdAw0XGIkShzP6uM5GlEZ LmEOqycSdmDQWrDHDj2K.Br6lulUKbPx9kqfeqTLHpT55dqW8wKG.vFUWoeL3vRTT9SMKoOSzliu lLFT5yHX1S6RDERz0Nc3pjivPMPHcWCutEG32osGZt86Kry21OrIiTOMv60PliQG1g0ZJXOyKsuf _xMcht.mISe8.YoIS.A27G_yaTxsVIxxissYQxoc0Vfe8uiNZV8VpZPBPIsuRF7wAhWgbDGpg90L XzxV7pZWQT1QfystkJoEK5ST03.ISXmdE8PX_AJH1dVLWX9BoGVRrpXuiV33Onr96Ep1Xe2_tKLE DK7T58zUGQiUmhfJj8zWzYpqbDnlnFG_Oq5Rq5d9TxlDukKy79kXjeFb.QH5NjaB7Kb91BVv39ed OUpJw3TQKW.CghFwJiVsE2pJmuuNAuox0V5MYypxdexP9LBFew_lZ.pPpfTGueVpj_VazGfCps.h 9H7FUjx604DETanneP_85WGDltajKyF2eXRYsHZp8NujkYWQ8paYtg1t4PiKwSX5.d27O_Tn4EBi IaDR8zE_W0..x5lFMQxrRpVVvavlkSWdSgC5ZUwKYGRMHs.116_dAcGfCDPy4OSYuG7sjSZ4GCJY QHuInX3QGlsTi63is7Nl8cOKFGyGGzLLuoCJLdyvn9hX0z3Zd6v_6Xr0W5Sjis4ZwO36EjeSmQUt jPQtVJiqm7Q4da4zw9lwxSrc9yCUV_qXzzghcNFB8FHWlEc_56u.n1pcz1HIGjxmpWqvrUVF2suI MS8vqD2pCjgb.R4W5jmuJnN9uYxZ6Sw1KvKba9_RZTfhuiNRta8ZqiRwSSMLAb5SRDKpFNLAQzfg c85zVU0vAMscFX8x93fgUOtDO6EEJibPhaNCcQl2WvYE2tN_01yFZIb_YKdkP5shX40i2q5_oGQ8 7rp8UVg-- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic314.consmr.mail.gq1.yahoo.com with HTTP; Thu, 23 Feb 2023 21:12:49 +0000 Received: by hermes--production-ne1-746bc6c6c4-7ksjp (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID e1c65c7f04acf230bc5b10be8247c77d; Thu, 23 Feb 2023 21:12:47 +0000 (UTC) Content-Type: text/plain; charset=us-ascii 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 Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.400.51.1.1\)) Subject: Re: FYI: Why META_MODE rebuilds so much for building again after installworld (no source changes) From: Mark Millard In-Reply-To: <42586.1677183334@kaos.jnpr.net> Date: Thu, 23 Feb 2023 13:12:35 -0800 Cc: Bryan Drewery , Current FreeBSD , Peter Content-Transfer-Encoding: quoted-printable Message-Id: References: <3345EBA5-A09C-4E3F-B94D-39F57F56BDBB@yahoo.com> <73088.1611797582@kaos.jnpr.net> <10819.1677108389@kaos.jnpr.net> <76FA98EF-6184-4D7E-A01F-0EE8117D0D10@yahoo.com> <29887.1677115125@kaos.jnpr.net> <27790339-240F-4C97-97C7-38AFD8DE03D5@yahoo.com> <7FB6F619-6E71-4075-8A6C-573564371DD5@yahoo.com> <2655.1677134606@kaos.jnpr.net> <242BB478-B2FE-4BCC-A56E-098F3FEB3EE1@yahoo.com> <42586.1677183334@kaos.jnpr.net> To: "Simon J. Gerraty" X-Mailer: Apple Mail (2.3731.400.51.1.1) X-Rspamd-Queue-Id: 4PN5Ml2RKlz3Gn7 X-Spamd-Bar: ---- 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-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N On Feb 23, 2023, at 12:15, Simon J. Gerraty wrote: > Mark Millard wrote: >> The contribution to the list is currently generated via >> use of: >>=20 >> .if ${.MAKE.LEVEL} =3D=3D 0 >=20 > Why is this guarded by .MAKE.LEVEL 0? > .MAKE.META.IGNORE_* should be largely irrelevant at level 0 > which in the DIRDEPS_BUILD is reserved for orchestration. > Even in the legacy build, level 0 would be just the top-level = makefiles > and anything dealing with meta files would be expected to be level 1 = or > greater.=20 I never found a stable notation that provides a reference to whichever of my /usr/obj/BUILDs/*/usr/main-src/*.*/ the build is for. (I've been showing just main-amd64-nodbg-clang amd64.amd64 examples but there are many more.) MAKEOBJDIR, OBJTOP, etc. all looked to vary. But here the only place relevant is that one absolute path, no alternatives should be used as these other things move around for where they reference. MAKEOBJDIRPREFIX is another one that looked to vary, despite the environment assignment that I use to get things started. Note, too the :=3D use. .MAKE.META.IGNORE_PATHS ends up with no references to MAKEOBJDIR or the like for my additions, just absolute paths. (I've also done experiments with :tA in use in the :=3D assignment.) -V.MAKE.META.IGNORE_PATHS showed the correct result with my content. I may have inferred too much from that for my :=3D use. (May be -V should not be based on .MAKE.LEVEL zero content as it can be misleading vs. what will actually be used?) So I was hoping for a "assigned once and inherited" status relative to submakes for .MAKE.META.IGNORE_PATHS . >> .for ignore_legacy_tool in awk cap_mkdb cat cp crunchgen crunchide dd = egrep env file2c gencat grep gzip jot lex lb ln m4 mkcsmapper mktemp mv = patch realpath rm sed sh touch truncate uudecode uuencode xargs >> .MAKE.META.IGNORE_PATHS+=3D = ${MAKEOBJDIR}/tmp/legacy/usr/sbin/${ignore_legacy_tool} >> .endfor >> .for ignore_other_tool in ctfconvert objcopy nm >> .MAKE.META.IGNORE_PATHS+=3D = ${MAKEOBJDIR}/tmp/usr/bin/${ignore_other_tool} >> .endfor >> .MAKE.META.IGNORE_PATHS:=3D ${.MAKE.META.IGNORE_PATHS} >> .endif >>=20 >> The :=3D use is how I avoided needing to worry about late binding >> substitutions for my additions (independent of the internals of >> make's specific .MAKE.META.IGNORE_PATHS handling). >=20 > Depending on value of MAKEOBJDIR the above may not work at all. > The default is >=20 > share/mk/src.sys.obj.mk:_default_makeobjdir=3D = $${.CURDIR:S,^$${SRCTOP},$${OBJTOP},} >=20 > In which case the above would not be correct. And I've not found any notation that is always correct but adjusts to what /usr/obj/BUILDs/*/usr/main-src/*.*/ I happen to be building for. The example that I've been showing is main-amd64-nodbg-clang with amd64.amd64=20 but there are other *-*-*dbg-* and *.* that I build for. (I have found multiple notations that work for -V.MAKE.META.IGNORE_PATHS .) I'm wondering if I need to invent a new, personal name that will not clash with official names and just use reference to to my name, adjusting my build scripts to provide the definition. So: I'm still searching for approriate notation, at least for the tmp/legacy/usr/ related paths. (The tmp/usr/bin/ experiment is more questionable it is appropriate overall.) Until I know a valid notational technique, expect to see experiments involved in what I do. Going the other way: if I'm to test something for you, let me know the context you want used instead of whatever my experiment status happens to be. >> For reference: >>=20 >> # more = ~/sys-build-scripts.amd64-host/make-main-amd64-nodbg-clang.amd64-host.sh >> kldload -n filemon && \ >> cd /usr/main-src/ && \ >> mkdir -p /usr/obj/BUILDs/main-amd64-nodbg-clang/sys-typescripts/ && \ >> script = /usr/obj/BUILDs/main-amd64-nodbg-clang/sys-typescripts/typescript-make-amd= 64-nodbg-clang-amd64-host-$(date +%Y-%m-%d:%H:%M:%S) \ >> env __MAKE_CONF=3D"/usr/home/root/src.configs/make.conf" = SRCCONF=3D"/dev/null" = SRC_ENV_CONF=3D"/usr/home/root/src.configs/src.conf.amd64-nodbg-clang.amd6= 4-host" \ >> WITH_META_MODE=3Dyes \ >> MAKEOBJDIRPREFIX=3D"/usr/obj/BUILDs/main-amd64-nodbg-clang" \ >> make $* =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Thu Feb 23 21:44:57 2023 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 4PN6573S2qz3snvK for ; Thu, 23 Feb 2023 21:45:15 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic310-21.consmr.mail.gq1.yahoo.com (sonic310-21.consmr.mail.gq1.yahoo.com [98.137.69.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 4PN6572F3Jz3P5x for ; Thu, 23 Feb 2023 21:45:15 +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=1677188712; bh=34uN9jFTNTtkCET+yDsJuiGjnLTlNdFof/1tbOUh5sI=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=fi2h2iZL0jsT1O3PEXyXcRfvgRTc9xHVTtyInyrKZWHwmJH7/JPbit6j+QcYkBzinumdx9RC27q+Lt4u6tYAZXW00qBDhS91Glp2PD9PtLUKUpRY3ovLIRqXIeY2CIhC9kZQtzcNV5Szlf2yJ5s0k6++2Zywlu88xdyZKH/o+kAOvVOjWDlv8CSSqHEt0g/rK44JTp6iFltbnezzN/CGtN4SYO2GGht6mijywkL6mE/ECR93euoDrj+iVY8YPuHbC/20PHYq2yD3bfrYggW7rZmueEM9JXNch8uPSTaykTgCQAuC/oefrwALfv91LQRttbNbSi6r+6lswcfiRqWeYA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1677188712; bh=URVXU0uyP420WMVPrSpkuZiBRzN9kEwgjJ8RfjOq7jK=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=dXz2i4BX6ElvW2Hk1S9uCsyxPZwbOgnG6RPv4rEmymoO1Q2FKUXg/DgmJdOkO0bEjp+motwa1cDwpiXSA2oMHLIonwEhrXMw/uXlGg3W1Alg5tXUIpOFFkuVEOm/SSY8+dYqDC+bAsePwa53k5SX3eQ72IpoauqwlIroEEV8xUMZhEKiOKj1JQhfoVor6q40/c21w7xNedMu/x6ksUuBvvIFI1iKc4Ytr6LE5jiw75y9Ny2VFcNhJo5lusdagWyi6dnAagtlqzm3IWu28ue7t979JJjAV1foqJI9yzFlUizaJtOeFC5Kuk6GZE15QFjk+UdaLc+0TBORzepAKM6gWg== X-YMail-OSG: 5qCryZIVM1nnMWTUhHCVyHSI51FVmfoERnKiNIGR.DPcVOrQ2RvoT6Gwcb5QzJl bv61Gpf_eeJ8uX_fbdbh8luWmpIY8bw9wlPZxbXZRQFNtKjW7_bs9dv8nIeBWujFP9F7z9H685Ly EXdcAsUMzP0097hfmm1iZpvtbDWQn2mYVWjAvD_23ARyAA_pO7_PkyUN1HI1_ppg8xwhd6k.yag9 iEQ99.iCgJxSsjCicAMSadK2wclNSwJmSH_Bd_zeTA510RL4QZ1MrWSgfvSjTkaR7uTaogQBdnUF rM5E3tYOdboPft3px0n9.aU_0Jog5tzinhdhJCufxATroKrvDCTDUmm7bDDyq_NuvOiDwjhtJPDq gzvHaesSNWbAVxpSD23hDLINgLUOT.64KuCpKSYP9awGJ1kw0yeaz9EuOoi7WAZWg7tphm0u2ucr iJ5aJ_Tetb_YNT7xIe7jcxGmJAy1isRgAZGHtVqXzPtbIYRwOjOaJW_VPtwQNbERSRapX.OZX7wI oWL8vcx_lMbB09QDm1BLXga53ZEJ.94AlGS8eQN4R9lCuOg3QS3W4zzgzBm.MPH6Yu2xscJmCCVa l5GLCxWO5kKqThJ_t3fkHqcxcXWsz5L2IjnmWW28MLTE7iNvC1TsDzKuRoFlyAV3lqFhTcezBu9B dEeUpuvUwpBvvVbbmXr099W3nGDTKOW8BC4qmAjAcnIzE4SAJC6mMBYfAz7krWqTJB3O1C4wL5kR YuRaV9yb9BYqAmkxEiyxeIE4_NJN4ZlXI6PRI8NmiYXiPICrnZMObqPqcSWXUt0TJZXgp_Hzzmc1 8dlXygDOI6WruMxCogauW_jNaqBFNw4TLvEJkHt8wDu4HHXCciRwl7veAQHsp6RETyG2Ywinjp65 TCpynOjTHzKtxM5tXPuiBEt5Q5Jf6iTTFp.IZAL7.9Bmc_aWCR..iBuAM31SWnUplvIr74ep6jXL JfHA6U2sKKCslMR_V3QQLolMaSfbB676e04EUaf1uI8_5WzWUuru3WujG9Qtu0Zv2AhNR9f8jKaA .DSwFCld5mV3M4Pd7IZHEhmxg_y4m1PizVfQrGLZ96HzDVtQWe6S9Z4E9910gO4d91bmd9hVP.7s sorLRetT6AlsjftbNpDd.2gUywIMoDu5WBi2U2jtbHKgFZbvaSK3Ip7IHZLOKzKi_91cPRPs0X9r 3DdrXU7BKxxe3M.ZV8TO4CGZ_IrH55knLH92QQhxLEbvUP95KfiA_rHl5NW0imO_pwHyfg.0D6SG G50I999KeNucO1ck8giLaNV.rGbqMH1Proh6BYIdFyPACKGSVfICZ37DS0RRZn8kXGukWdtcq7sd jtBSEplRnZlKcHYIN8mqvm2UKvVDcVGs87iSgjyaoQJBtspdS2f.F5wY3TN7dBzoLBR0ZJ3RGH8e hwQA3QWdVj3LQVRaKsDPUlI8X8hK_AbJBXC7tZn8VoLfE6_0HK6nfM3njPF7Teu6bEsLaTUnUfFz .Rk_jZJbyugLeBqjjT1fQ9nbupo7129oeaHcNmLV4DqJ22Veu_oLWt._uju3HeZtzjX0CkuiLvuG WDga29LhURxyapM7w_jDRi2Qyzfo.QGKpZjpM9dCahJWwbDXEUOtyOxng4nmFQYYcTMJUWuk1T0c AcUgrsi3lR5vb.KH83Q6d_sgpeFqfLJ8vPS8AH8e46OlcmcDULga5insVerHmZb68QG0C__uoMLE YRGg9gdMsyVSTtgcijvO8u5RRUFk7A0T7rfohexbRAAVwOFHK6bih.jfl.MDBYnWY3aFMUXDCOdP f4YSeF8PPWcpHrHVgMp8WrPBW6IHJZN9ePtPkaYr.v0dtCB6u4OdVg5IUnsnbtX5iSsd8EKcyR0G iiMSTYXSLeo0aWA2BevjkmlRv4dcv7AjaOuKyOScsTcWWxpXe.2ela2gHslXoUbiXRzxC5_cEYZA EsuI0MqvswSQnO4_21DND_Xo369qPhO6XeOD.YGTTy6gtBpdZbE_x6F2diyAdqc0_H4yRc5tbqBu TNU0dcyrc3hq8wV_QcUFoxF2Grifp1.sKbLoxkSnqC.tumpHGajmdaQ9lHZPZSKd7Yxyptv.qLYU 1w7W8tcgzNYrSXEEOqM.8CQq4zbowC3JtZwJ.u4GYzIo7KwMItCR89wMc0SSg7QYuFBXkop3i0_. 4J_6F6voNyyII7wE9tgMALIerRsp2w1hGlafDlt7eWIkTf3mpiSrV7geK6wYg8TE9ROGtsHmpI.E zTOftsnLCenS761KdC_uB9UHiWGkNH0ZolzUtK..6305TySbZqPhyCh.JdYhu0nYA.y6fxCQQnzU wf.JXVw-- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic310.consmr.mail.gq1.yahoo.com with HTTP; Thu, 23 Feb 2023 21:45:12 +0000 Received: by hermes--production-bf1-57c96c66f6-jdmts (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID a71aa7c3c85a9f05b1e8d3b655ffd5f2; Thu, 23 Feb 2023 21:45:10 +0000 (UTC) Content-Type: text/plain; charset=us-ascii 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 Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.400.51.1.1\)) Subject: Re: FYI: Why META_MODE rebuilds so much for building again after installworld (no source changes) From: Mark Millard In-Reply-To: <30.1677183903@kaos.jnpr.net> Date: Thu, 23 Feb 2023 13:44:57 -0800 Cc: Bryan Drewery , Current FreeBSD , Peter Content-Transfer-Encoding: quoted-printable Message-Id: References: <3345EBA5-A09C-4E3F-B94D-39F57F56BDBB@yahoo.com> <73088.1611797582@kaos.jnpr.net> <10819.1677108389@kaos.jnpr.net> <76FA98EF-6184-4D7E-A01F-0EE8117D0D10@yahoo.com> <29887.1677115125@kaos.jnpr.net> <27790339-240F-4C97-97C7-38AFD8DE03D5@yahoo.com> <72419.1677133429@kaos.jnpr.net> <30.1677183903@kaos.jnpr.net> To: "Simon J. Gerraty" X-Mailer: Apple Mail (2.3731.400.51.1.1) X-Rspamd-Queue-Id: 4PN6572F3Jz3P5x X-Spamd-Bar: ---- 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-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N [Note for "how many separate bmake instances are in that log?": I do not know how to tell how many submakes are run total. It was with -j32 on the threadripper 1950X, if that is was you were after.] On Feb 23, 2023, at 12:25, Simon J. Gerraty wrote: > Mark Millard wrote: >>>> . . . >=20 >> I got past the issue using :=3D before reading the above. >> (I'm also using MAKEOBJDIR instead of OBJTOP currently.) >=20 > Per my last response, I'd be pretty sure MAKEOBJDIR is incorrect. Which still leaves me experimenting to find a correct reference. Do you know notation will always lead to the same absolute path with the proper /usr/obj/BUILDs/*/usr/main-src/*.*/ prefix ? (I've been showing just the main-amd64-nodbg-clang and amd64.amd64 combination but there are many more.) >>>>> .MAKE.META.IGNORE_PATHS+=3D ${OBJTOP}/tmp/ >>>>=20 >>>> (Ignoring the variability of OBJTOP issue . . .) >>>>=20 >>>> I do not expect that would work: ignoring things >>>> it likely should not. >>>=20 >>> Sure, but it may be useful as an experiment to ensure things are >>> behaving as expected. >>=20 >> As a test: >>=20 >> .if ${.MAKE.LEVEL} =3D=3D 0 >> .MAKE.META.IGNORE_PATHS+=3D ${MAKEOBJDIR:tA}/tmp/ >> .MAKE.META.IGNORE_PATHS:=3D ${.MAKE.META.IGNORE_PATHS} >> .endif >=20 > Lose the .if ${.MAKE.LEVEL} =3D=3D 0 > it is almost certainly keeping things from working as expected. What do you want tested instead of MAKEOBJDIR ? I'm taking a guess (no .MAKE.LEVEL use): .MAKE.META.IGNORE_PATHS+=3D ${OBJTOP:tA}/tmp/ .MAKE.META.IGNORE_PATHS:=3D ${.MAKE.META.IGNORE_PATHS:tA} >> I still get things like: >>=20 >> = /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/sys/GENERI= C-NODBG/modules/usr/main-src/sys/modules/zlib/x86.meta: 23: file = '/usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/tmp/legac= y/usr/sbin/realpath' is newer than the target... >> Building = /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/sys/GENERI= C-NODBG/modules/usr/main-src/sys/modules/zlib/x86 >=20 > Because that will not be level 0 and so .MAKE.META.IGNORE_PATHS is not > set. I tried the above and I still get (picking to look for tmp/legacy/usr/sbin/ln examples): = /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/sys/GENERI= C-NODBG/modules/usr/main-src/sys/modules/aac/opt_scsi.h.meta: 22: file = '/usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/tmp/legac= y/usr/sbin/ln' is newer than the target... Building = /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/sys/GENERI= C-NODBG/modules/usr/main-src/sys/modules/aac/opt_scsi.h -- = /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/sys/GENERI= C-NODBG/modules/usr/main-src/sys/modules/asmc/opt_acpi.h.meta: 22: file = '/usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/tmp/legac= y/usr/sbin/ln' is newer than the target... Building = /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/sys/GENERI= C-NODBG/modules/usr/main-src/sys/modules/asmc/opt_acpi.h -- . . . and (looking for realpath examples): = /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/sys/GENERI= C-NODBG/modules/usr/main-src/sys/modules/accf_dns/machine.meta: 23: file = '/usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/tmp/legac= y/usr/sbin/realpath' is newer than the target... Building = /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/sys/GENERI= C-NODBG/modules/usr/main-src/sys/modules/accf_dns/machine = /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/sys/GENERI= C-NODBG/modules/usr/main-src/sys/modules/accf_data/machine.meta: 23: = file = '/usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/tmp/legac= y/usr/sbin/realpath' is newer than the target... = /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/sys/GENERI= C-NODBG/modules/usr/main-src/sys/modules/accf_http/machine.meta: 23: = file = '/usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/tmp/legac= y/usr/sbin/realpath' is newer than the target... Building = /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/sys/GENERI= C-NODBG/modules/usr/main-src/sys/modules/accf_http/machine -- = /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/sys/GENERI= C-NODBG/modules/usr/main-src/sys/modules/ae/machine.meta: 23: file = '/usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/tmp/legac= y/usr/sbin/realpath' is newer than the target... Building = /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/sys/GENERI= C-NODBG/modules/usr/main-src/sys/modules/ae/machine = /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/sys/GENERI= C-NODBG/modules/usr/main-src/sys/modules/acl_posix1e/machine.meta: 23: = file = '/usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/tmp/legac= y/usr/sbin/realpath' is newer than the target... Building = /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/sys/GENERI= C-NODBG/modules/usr/main-src/sys/modules/acl_posix1e/machine -- . . . >>=20 >> and: >>=20 >> = /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/sys/GENERI= C-NODBG/modules/usr/main-src/sys/modules/xl/opt_platform.h.meta: 12: = file = '/usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/tmp/legac= y/usr/sbin/ln' is newer than the target... >> Building = /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/sys/GENERI= C-NODBG/modules/usr/main-src/sys/modules/xl/opt_platform.h >>=20 >> for both of a pair of back-to-back runs of buildworld buildkernel. >>=20 >> FYI: The file system is zfs with mounts that look >> like: >>=20 >> zoptb /zoptb >> zoptb/BUILDs /usr/obj/BUILDs >> . . . >> zoptb/BUILDs/main-amd64-nodbg-clang = /usr/obj/BUILDs/main-amd64-nodbg-clang >> . . . >> zoptb/ROOT/main-amd64 / >> . . . >> zoptb/tmp /tmp >> . . . >>=20 >> # bectl list >> BE Active Mountpoint Space Created >> 13S-amd64 - - 4.97G 2021-08-20 16:57 >> 13_0R-amd64 - - 4.30G 2021-08-20 16:56 >> 13_1R-amd64 - - 4.12G 2022-03-10 12:38 >> main-amd64 NR / 7.42G 2023-02-19 15:37 >> old-main-amd64 - - 2.25G 2023-02-09 19:07 >>=20 >> (I use zfs in order to use bectl on a couple of >> systems, not for redundancy.) >>=20 >>=20 >>>> Also, I'd rather grow a smaller set of ignores >>>> gradually to make it easier to detect if an >>>> addition starts causing a problem and can be >>>> backed out. Starting with everything ignored >>>> would make things much harder to figure out >>>> when ignoring creates a problem. >>>=20 >>> Yes. >>>=20 >>>>=20 >>>>> You might need ${OBJTOP:tA}/tmp/ >>>>> or both. >>>=20 >>> I found it necessary in the unit tests to add :tA to both TMPDIR >>> and .OBJDIR to get sane result on one test platform. >>>=20 >>>>>> It is using paths that match the -dM output lines ( sbin >>>>>> use despite sbin -> ../bin being a symbolic link). >>>=20 >>> use :tA if you want to ensure consistent results. >>=20 >> So, for each: >>=20 >> .MAKE.META.IGNORE_PATHS+=3D = ${MAKEOBJDIR}/tmp/legacy/usr/sbin/${ignore_legacy_tool} >>=20 >> I need to form an overall :tA on the path? Something >> like: >>=20 >> .if ${.MAKE.LEVEL} =3D=3D 0 >=20 > I think you need to first get rid of that level 0 check before > worrying about anything else. Done. But it appears to make no difference. >> .for ignore_legacy_tool in awk cap_mkdb cat cp crunchgen crunchide dd = egrep env file2c gencat grep gzip jot lex lb ln m4 mkcsmapper mktemp mv = patch realpath rm sed sh touch truncate uudecode uuencode >> xargs >> IGNORELEGACY_${ignore_legacy_tool}=3D = ${MAKEOBJDIR}/tmp/legacy/usr/sbin/${ignore_legacy_tool} >> .MAKE.META.IGNORE_PATHS+=3D ${IGNORELEGACY_${ignore_legacy_tool}:tA} >> .endfor >> .for ignore_other_tool in ctfconvert objcopy nm >> IGNOREOTHER_${ignore_other_tool}=3D = ${MAKEOBJDIR}/tmp/usr/bin/${ignore_other_tool} >> .MAKE.META.IGNORE_PATHS+=3D ${IGNOREOTHER_${ignore_other_tool}:tA} >> .endfor >> .MAKE.META.IGNORE_PATHS:=3D ${.MAKE.META.IGNORE_PATHS} >> .endif >>=20 >> Such seems to make no difference to the text reported via >> -dV -V.MAKE.META.IGNORE_PATHS in my context. >=20 > Yes, right now I think your main problem is only setting > .MAKE.META.IGNORE_PATHS at level 0 Not as far as I can see in the results. (Note: I did not start with explicit use of .MAKE.LEVEL . It was just something I'd added into my experiments recently. Nothing that I've tried has worked. I keep exploring, looking for evidence of some way being able to control the behavior.) =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Thu Feb 23 22:03:56 2023 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 4PN6XM3CXcz3spT5 for ; Thu, 23 Feb 2023 22:05:23 +0000 (UTC) (envelope-from sjg@juniper.net) Received: from mx0b-00273201.pphosted.com (mx0b-00273201.pphosted.com [67.231.152.164]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.pphosted.com", Issuer "Thawte RSA CA 2018" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4PN6XM2YTvz3R9y; Thu, 23 Feb 2023 22:05:23 +0000 (UTC) (envelope-from sjg@juniper.net) Authentication-Results: mx1.freebsd.org; none Received: from pps.filterd (m0108163.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 31NIeY3u011769; Thu, 23 Feb 2023 14:05:01 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=to : cc : subject : in-reply-to : references : from : mime-version : content-type : content-id : content-transfer-encoding : date : message-id; s=PPS1017; bh=GrfPwr4aA/6KiLVMm6Zwp+3idv4gPIh6ux591vBDY5Q=; b=oVVhuGM1KP+WZU3GMFbIg+hzGvZdPzAxfNOlIuQU4BCNuB5OCxmf+4r2BRInoSRG6SkM GJjQZ94JFQkG1yo1QPsATQ1NEF4tgU2NWJMeORiOu4VPDLjx1zYUGEfXWudGSZJT2h4x ACkHn8IzqbxCxPr3FPnFNv4+rtyF8IAKImA/mQgzEEKf3nOxuKLnHCTvWQTDheyxmYDn mPY8/DRZgHxckQqjv04Zg4xa4C16LU1YajpgyibR17e+UKMiuwDyUtYYndLgDTW2coBH 6BrO+kN0uhYIhenTshByTA9utTmzgr+wLu+vW2/6wheKSDw26oJ+Dd9I2wmqAM3WCXPi fQ== Received: from mw2pr02cu002-vft-obe.outbound.protection.outlook.com (mail-westus2azlp17013031.outbound.protection.outlook.com [40.93.10.31]) by mx0b-00273201.pphosted.com (PPS) with ESMTPS id 3nx8gssa0j-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 23 Feb 2023 14:05:01 -0800 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=kIBg1THXB50qNYjlCJegEd4F7YEr9Z00Sq78FpLkreiv4Ox2PywA474Yu8Opwqh9LKDKh7zOefscTa6BzvfMRi0o/NkuVA+6qlvf5Wk0uz9wNRZ3zAnwtnmvY9Sb+yUjp92WK9R4nhwz5Mxjcy9XtKLynCaAFLzCzUlaWJpGRlhIgWdVAUVbQeUDFRWZYYS6nqBZh/mDEFAgUTiffv/dTxov8+jyJcC/fIekQozgENxG7fo0Wyx/mSNneCpTdDg6Q5sBf4F6QR7jBxMucu2pTwZsmU0oZNe0jYRCcpX6qRDKKISKjCW0QKx7PsJTzIkz71aSfxmgsnSXRvU0KJHI3Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=GrfPwr4aA/6KiLVMm6Zwp+3idv4gPIh6ux591vBDY5Q=; b=CqWL7JMtz9nrta9gJmW7sfSopKHkVMjZj39D6QTGigfJ4iQ+n/wNdPFXVagA7343zy8B24wAR49pc8wI0rHRfJ/sWBlPOQAZi9QgCLtm738HY1SARCiBnztMgrCS6uuF8Xfl6jtLlbeNcJC8zxBcctdypW+6lipVEEGzGSim1QrIgz27Nxb1ivU2W4wd7VWPS0z+hxLMb4k0+DVpTWpySLb5vDY3e5+pY1HZrP3iEOKGvCMn5+K9qESj9f2cOSn7CVlh9MeGLGaPUy8286c665MONqj3mc+xk3WZ9BcYQ7wvK18An44tUXwNUXybMQXWLgMKOygqHzXAgWgmZdioQw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=softfail (sender ip is 66.129.239.14) smtp.rcpttodomain=yahoo.com smtp.mailfrom=juniper.net; dmarc=fail (p=reject sp=reject pct=100) action=oreject header.from=juniper.net; dkim=none (message not signed); arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=GrfPwr4aA/6KiLVMm6Zwp+3idv4gPIh6ux591vBDY5Q=; b=VwiPyR4o2jyIw0rPQDEpCujs+WhcxotgdajGy1bNMxwH/Qh6XYhr1yqQ989exv5VP34xJB8XhAXrxJhmKvkjW1SuuwLw/9+srDo13cGcVBJYD/tjzewWQydY/BwOYcW8LQKmJIgL7bLKXCMVmHei0IrcqsLNOFSDp+nt6htt4Jo= Received: from DM6PR06CA0068.namprd06.prod.outlook.com (2603:10b6:5:54::45) by DM6PR05MB5353.namprd05.prod.outlook.com (2603:10b6:5:5b::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6134.21; Thu, 23 Feb 2023 22:04:56 +0000 Received: from DM6NAM12FT060.eop-nam12.prod.protection.outlook.com (2603:10b6:5:54:cafe::e1) by DM6PR06CA0068.outlook.office365.com (2603:10b6:5:54::45) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6134.21 via Frontend Transport; Thu, 23 Feb 2023 22:04:56 +0000 X-MS-Exchange-Authentication-Results: spf=softfail (sender IP is 66.129.239.14) smtp.mailfrom=juniper.net; dkim=none (message not signed) header.d=none;dmarc=fail action=oreject header.from=juniper.net; Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.14 as permitted sender) Received: from p-exchfe-eqx-01.jnpr.net (66.129.239.14) by DM6NAM12FT060.mail.protection.outlook.com (10.13.179.128) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6156.5 via Frontend Transport; Thu, 23 Feb 2023 22:04:56 +0000 Received: from p-exchbe-eqx-02.jnpr.net (10.104.9.15) by p-exchfe-eqx-01.jnpr.net (10.104.9.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.30; Thu, 23 Feb 2023 16:04:55 -0600 Received: from p-exchbe-eqx-02.jnpr.net (10.104.9.15) by p-exchbe-eqx-02.jnpr.net (10.104.9.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.30; Thu, 23 Feb 2023 16:04:55 -0600 Received: from p-mailhub01.juniper.net (10.104.20.6) by p-exchbe-eqx-02.jnpr.net (10.104.9.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.30 via Frontend Transport; Thu, 23 Feb 2023 16:04:55 -0600 Received: from kaos.jnpr.net (kaos.jnpr.net [172.23.255.201]) by p-mailhub01.juniper.net (8.14.4/8.11.3) with ESMTP id 31NM4tWP007414; Thu, 23 Feb 2023 14:04:55 -0800 (envelope-from sjg@juniper.net) Received: by kaos.jnpr.net (Postfix, from userid 1377) id 5CC5621199; Thu, 23 Feb 2023 14:03:56 -0800 (PST) Received: from kaos.jnpr.net (localhost [127.0.0.1]) by kaos.jnpr.net (Postfix) with ESMTP id 5965821198; Thu, 23 Feb 2023 14:03:56 -0800 (PST) To: Mark Millard CC: Bryan Drewery , Current FreeBSD , Peter , Subject: Re: FYI: Why META_MODE rebuilds so much for building again after installworld (no source changes) In-Reply-To: References: <3345EBA5-A09C-4E3F-B94D-39F57F56BDBB@yahoo.com> <73088.1611797582@kaos.jnpr.net> <10819.1677108389@kaos.jnpr.net> <76FA98EF-6184-4D7E-A01F-0EE8117D0D10@yahoo.com> <29887.1677115125@kaos.jnpr.net> <27790339-240F-4C97-97C7-38AFD8DE03D5@yahoo.com> <7FB6F619-6E71-4075-8A6C-573564371DD5@yahoo.com> <2655.1677134606@kaos.jnpr.net> <242BB478-B2FE-4BCC-A56E-098F3FEB3EE1@yahoo.com> <42586.1677183334@kaos.jnpr.net> Comments: In-reply-to: Mark Millard message dated "Thu, 23 Feb 2023 13:12:35 -0800." From: "Simon J. Gerraty" X-Mailer: MH-E 8.6+git; nmh 1.7.1; GNU Emacs 28.1 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 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <99202.1677189836.1@kaos.jnpr.net> Content-Transfer-Encoding: quoted-printable Date: Thu, 23 Feb 2023 14:03:56 -0800 Message-ID: <30.1677189836@kaos.jnpr.net> X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: DM6NAM12FT060:EE_|DM6PR05MB5353:EE_ X-MS-Office365-Filtering-Correlation-Id: 6b799ec1-92f6-442c-e59f-08db15e9ffb5 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: iWgDT+VV+hGjhy8yiWdgbVBrSr9cvajhAYEBWoc1Ws2HUnUbzdMH9bOtgkBKH3Frz/xJAySMUdD7U3p0yyXFzo042XkDzJ7wyjbUVAu3LKc7HKLUZeqeAngNIxr8mXFnIaQHcs2JE/Ske/X85JFsNnfC/twGW0VGPG1m64U2C0vFpz0WKztnFmRMrZvDVP4oFik/mBS40lKCWB+Gli7qxEeegtrPqjrzeDexQfStsCGJY2dn8QPIr+d0S2Yi2jzrBR/f/u7yIGX4AY5TKN8btLkC8YaGbQYHs8aUvrQ7AMO2D8rheF00xr1j0H5iSikSi2MGNFYvsXYlSah+jXlpmIrQcJQ3Is2lMld/WhuvcJLtOZactd8+M/FyCs5kIP1ey1UC1XYyUU3sXoaEFXQ8dApD8r0JDHfxSslvUdnuoZQ1gHEMxSPZmUgFq1VYv1pOnTVHcZWl1x7wFfi6MHp5LBxob0J5AHKVCIPOgxmT1f7PfgwMDvIgZUfJq3ZqOU8oWraygKqhVqPY43dAfR/xbJsdVWh7t5ccDwl1p50xYNfHMXWcwSbsUg/grcHWbDqdEGPqIfg/v1LegQcS96XPe4drC0K3E9xiVo/nCt6PLCvaVjG/FgAjELtD10eS2CUotizwHzv5Lr8G9kBjf+iNZx3Pu01GdiqnAQuAi/qtwOwDD3UpnVBKPSvKm2+n0xBqs8ZZT8tUtRXlSefpFgjvqYPJnZhAeBnCuH5y3jUC2DJ0d0+J/tguw7iYvcXfarQwir7fDlgqIC1OQFXH1qga9BL3H/1ahkt8zTo3UVT2/9k= X-Forefront-Antispam-Report: CIP:66.129.239.14;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:p-exchfe-eqx-01.jnpr.net;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230025)(4636009)(376002)(346002)(39860400002)(396003)(136003)(451199018)(40470700004)(36840700001)(46966006)(86362001)(8936002)(41300700001)(2906002)(82740400003)(36860700001)(356005)(83380400001)(81166007)(5660300002)(478600001)(70586007)(316002)(7696005)(4326008)(6916009)(70206006)(8676002)(6266002)(9686003)(7126003)(55016003)(40460700003)(186003)(26005)(40480700001)(82310400005)(107886003)(336012)(54906003)(47076005)(36900700001);DIR:OUT;SFP:1102; X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Feb 2023 22:04:56.3793 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 6b799ec1-92f6-442c-e59f-08db15e9ffb5 X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4;Ip=[66.129.239.14];Helo=[p-exchfe-eqx-01.jnpr.net] X-MS-Exchange-CrossTenant-AuthSource: DM6NAM12FT060.eop-nam12.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR05MB5353 X-Proofpoint-GUID: tEXEnV6ntac6bLIBP5XoVuCQrxy-CyGO X-Proofpoint-ORIG-GUID: tEXEnV6ntac6bLIBP5XoVuCQrxy-CyGO X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.219,Aquarius:18.0.930,Hydra:6.0.562,FMLib:17.11.170.22 definitions=2023-02-23_13,2023-02-23_01,2023-02-09_01 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 clxscore=1015 mlxscore=0 impostorscore=0 lowpriorityscore=0 phishscore=0 mlxlogscore=999 priorityscore=1501 spamscore=0 adultscore=0 bulkscore=0 suspectscore=0 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2212070000 definitions=main-2302230182 X-Rspamd-Queue-Id: 4PN6XM2YTvz3R9y X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:22843, ipnet:67.231.152.0/24, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N Mark Millard wrote: > So I was hoping for a "assigned once and > inherited" status relative to submakes for > .MAKE.META.IGNORE_PATHS . No, .MAKE.* are specifically named to ensure they cannot come from the environment. So bounding them in a check for level 0 pretty much ensures they have no effect. > > In which case the above would not be correct. > = > And I've not found any notation that is always correct I think your fundamental issue is above. These variables apply only per make instance. They are not inherited, they are not global. As I mentioned previously, there is no variablity of OBJTOP within the context of a single make instance - at least not once it starts running targets. > but adjusts to what /usr/obj/BUILDs/*/usr/main-src/*.*/ > I happen to be building for. The example that I've > been showing is main-amd64-nodbg-clang with amd64.amd64 > but there are other *-*-*dbg-* and *.* that I build for. Sorry I guess I'm not following what you are saying as I cannot see how any of that is relevant. > = > (I have found multiple notations that work for > -V.MAKE.META.IGNORE_PATHS .) Sorry not sure what that means. Note that when you do make -V BLAH you are seeing the value of BLAH as level 0 sees it - which in your setup looks right. But because of your conditional on level 0 the effect is not what you want once the build gets going. = > I'm wondering if I need to invent a new, personal name > that will not clash with official names and just use > reference to to my name, adjusting my build scripts > to provide the definition. Sorry, a name for what? > = > So: I'm still searching for approriate notation, at least > for the tmp/legacy/usr/ related paths. (The tmp/usr/bin/ > experiment is more questionable it is appropriate overall.) Again not really following. If there are paths under tmp/legacy/usr/ that should be ignored by meta.c - why would that not be so for everyone? > Until I know a valid notational technique, expect to > see experiments involved in what I do. Going the other > way: if I'm to test something for you, let me know the > context you want used instead of whatever my experiment > status happens to be. > = > >> For reference: > >> > >> # more ~/sys-build-scripts.amd64-host/make-main-amd64-nodbg-clang.amd= 64-host.sh > >> kldload -n filemon && \ > >> cd /usr/main-src/ && \ > >> mkdir -p /usr/obj/BUILDs/main-amd64-nodbg-clang/sys-typescripts/ && \ > >> script /usr/obj/BUILDs/main-amd64-nodbg-clang/sys-typescripts/typescr= ipt-make-amd64-nodbg-clang-amd64-host-$(date +%Y-%m-%d:%H:%M:%S) \ > >> env __MAKE_CONF=3D"/usr/home/root/src.configs/make.conf" SRCCONF=3D"/= dev/null" SRC_ENV_CONF=3D"/usr/home/root/src.configs/src.conf.amd64-nodbg-= clang.amd64-host" \ > >> WITH_META_MODE=3Dyes \ > >> MAKEOBJDIRPREFIX=3D"/usr/obj/BUILDs/main-amd64-nodbg-clang" \ > >> make $* This is why we introduced variables like SRCTOP and OBJTOP behind which yo= u can hide all the above. It should not matter what or how OBJTOP gets its value it should be useful. .MAKE.META.IGNORE_PATHS +=3D ${OBJTOP}/tmp/legacy/usr should result in nothing under ${OBJTOP}/tmp/legacy/usr causing a target to be out of date - just because it is newer. From nobody Thu Feb 23 22:34:57 2023 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 4PN7DB2tQQz3ss4Z for ; Thu, 23 Feb 2023 22:36:26 +0000 (UTC) (envelope-from sjg@juniper.net) Received: from mx0b-00273201.pphosted.com (mx0b-00273201.pphosted.com [67.231.152.164]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.pphosted.com", Issuer "Thawte RSA CA 2018" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4PN7DB0Fdgz3nRG; Thu, 23 Feb 2023 22:36:25 +0000 (UTC) (envelope-from sjg@juniper.net) Authentication-Results: mx1.freebsd.org; none Received: from pps.filterd (m0108162.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 31NITGn1013809; Thu, 23 Feb 2023 14:36:04 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=to : cc : subject : in-reply-to : references : from : mime-version : content-type : content-id : content-transfer-encoding : date : message-id; s=PPS1017; bh=h49AyXInOPYMvYFhu5QRrhfAwDP5mE4EsIBJmPhyv1g=; b=HwIXU27oE5CuihK3wiZvYeNy7AxIVIUlPr/f+pDqT+513H9aaSSnPCkXuyCmL3f+/OEn iE/ZnBO6THHZ4MFlPB8SYYFcoLV1kkeKLcsBhMTYhwLyDkNkZPO7X7U1quCiHO0FYlwe 358ih9JZpGhGhnOGQt9Bxbk0djfT09RJ2gbANW6tCPltIAKYRIeBVvIjO82PG2CicCp6 HmG5RNYnsg0vn/scwn9yTPzNShiSRHCrCITDMkPQ7UV654i5vLTiaRCeSThF1ch9JN2G G5xk6h1fxEFxnLMgVq4pDyTQ31N5n4cYtNUhEFLc/qciN9rSlZR422xcLTMfgyz9/nm1 Ew== Received: from bl0pr02cu005-vft-obe.outbound.protection.outlook.com (mail-eastusazlp17012028.outbound.protection.outlook.com [40.93.11.28]) by mx0b-00273201.pphosted.com (PPS) with ESMTPS id 3nwy85adtk-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 23 Feb 2023 14:36:04 -0800 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=EgHTWnojy077a519X4qiFh3mRkG1c+lgpq4SG2p4fLTew2FN9p56Wj7EgiE5fD85i5w66qn/gTb7A9aeJ7aLqP273lrj1RbbTtp+8BMKSz6AaIMQYNq2OtAMy0LI/O7643sMlCL5Aj/Ab7lQac6zcTMgKlPlMKG7RqZvoB1nJSVaiQTiWdLXJu9RbrtNSc7tlo0ZyH+OU2E7+PyUHVmc0YiGypTKSyHuH7UuGtQiKxpXOkrk8BJ8MNszGu0hDlzTZADTE+4GHp/SoK7q9E3p8ncg7/o9JaqBY1NG6KKWdddklcV2lDN80vClWtgGqBImyPFZL9KdMlwuhkWMrMUGlg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=h49AyXInOPYMvYFhu5QRrhfAwDP5mE4EsIBJmPhyv1g=; b=krWiYL1hQuf6lC5dPRD/3LiOL+ca8vzzgAQYz2Mc+JNUMxDmVpb8f2s7LQSlvqxHQTswUtpvVvltX+c2GzOT49UQa9dVWQcZ3yJ1Uck6/t6zC7e4Wju2lCIcckMMoGEDtFs1qhucQblEXelsx33GOa9lpQmP1Cgw9k91XTLkjTFAziXwaioTwdqPnWHenYHw20fWZ67oTqmDnt5+F5kdl4DYcgCMhUoySIvxcfweauyyYY4nUF0fJr77v65nvFZD0rzQ/DMyi0RmY0IRspDcsO8IoYhbD5eeryAKyrgLOBE6KgdiLUnsgYAtXw++4gtunJWR0iuIGcDAdMY5qqYYjQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=softfail (sender ip is 66.129.239.14) smtp.rcpttodomain=yahoo.com smtp.mailfrom=juniper.net; dmarc=fail (p=reject sp=reject pct=100) action=oreject header.from=juniper.net; dkim=none (message not signed); arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=h49AyXInOPYMvYFhu5QRrhfAwDP5mE4EsIBJmPhyv1g=; b=GvQvFPUSXr23bC1QUw3fpqTAt28pTWE2pvWuKluTmmCnzXXzXKx5qjR8lXIWj3wON9c2KUiUlmAQyVzfvIe/qjdW/THvRZNl8Bxqiim/H7J62RSO+wCkRfTml9FKA/QJWDFK1BIHiIeHJc3mRpx+hYjGmD28NoyNGJw3LL0CYiQ= Received: from DM6PR06CA0083.namprd06.prod.outlook.com (2603:10b6:5:336::16) by CH2PR05MB7096.namprd05.prod.outlook.com (2603:10b6:610:47::30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6134.19; Thu, 23 Feb 2023 22:35:59 +0000 Received: from DM6NAM12FT043.eop-nam12.prod.protection.outlook.com (2603:10b6:5:336:cafe::53) by DM6PR06CA0083.outlook.office365.com (2603:10b6:5:336::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6134.21 via Frontend Transport; Thu, 23 Feb 2023 22:35:59 +0000 X-MS-Exchange-Authentication-Results: spf=softfail (sender IP is 66.129.239.14) smtp.mailfrom=juniper.net; dkim=none (message not signed) header.d=none;dmarc=fail action=oreject header.from=juniper.net; Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.14 as permitted sender) Received: from p-exchfe-eqx-01.jnpr.net (66.129.239.14) by DM6NAM12FT043.mail.protection.outlook.com (10.13.179.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6134.19 via Frontend Transport; Thu, 23 Feb 2023 22:35:59 +0000 Received: from p-exchbe-eqx-02.jnpr.net (10.104.9.15) by p-exchfe-eqx-01.jnpr.net (10.104.9.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.30; Thu, 23 Feb 2023 16:35:58 -0600 Received: from p-mailhub01.juniper.net (10.104.20.6) by p-exchbe-eqx-02.jnpr.net (10.104.9.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.30 via Frontend Transport; Thu, 23 Feb 2023 16:35:58 -0600 Received: from kaos.jnpr.net (kaos.jnpr.net [172.23.255.201]) by p-mailhub01.juniper.net (8.14.4/8.11.3) with ESMTP id 31NMZuI2014770; Thu, 23 Feb 2023 14:35:57 -0800 (envelope-from sjg@juniper.net) Received: by kaos.jnpr.net (Postfix, from userid 1377) id E41CC2119D; Thu, 23 Feb 2023 14:34:57 -0800 (PST) Received: from kaos.jnpr.net (localhost [127.0.0.1]) by kaos.jnpr.net (Postfix) with ESMTP id E2F9D21028; Thu, 23 Feb 2023 14:34:57 -0800 (PST) To: Mark Millard CC: Bryan Drewery , Current FreeBSD , Peter , Subject: Re: FYI: Why META_MODE rebuilds so much for building again after installworld (no source changes) In-Reply-To: References: <3345EBA5-A09C-4E3F-B94D-39F57F56BDBB@yahoo.com> <73088.1611797582@kaos.jnpr.net> <10819.1677108389@kaos.jnpr.net> <76FA98EF-6184-4D7E-A01F-0EE8117D0D10@yahoo.com> <29887.1677115125@kaos.jnpr.net> <27790339-240F-4C97-97C7-38AFD8DE03D5@yahoo.com> <72419.1677133429@kaos.jnpr.net> <30.1677183903@kaos.jnpr.net> Comments: In-reply-to: Mark Millard message dated "Thu, 23 Feb 2023 13:44:57 -0800." From: "Simon J. Gerraty" X-Mailer: MH-E 8.6+git; nmh 1.7.1; GNU Emacs 28.1 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 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <32946.1677191697.1@kaos.jnpr.net> Content-Transfer-Encoding: quoted-printable Date: Thu, 23 Feb 2023 14:34:57 -0800 Message-ID: <36040.1677191697@kaos.jnpr.net> X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: DM6NAM12FT043:EE_|CH2PR05MB7096:EE_ X-MS-Office365-Filtering-Correlation-Id: 1a167c9f-581c-4850-81a3-08db15ee563e X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: fsYj/DMcneuQ106OGI/75LlLj8StZiHUIrRIRc1pephsu/sTDg+tX7Xc6jPHo9Wc52YG6u2lMyn5LeAt3/Dvl7XWspkz/KrHE7Y/LsyoKrdDUDVRrjrtDnAISVLBJD0tSy5VtVTB4TMz5NERXPMxjhsH9CQmrbFqFYPYrCFGTPSbJz7z3mkq5EzyuLQyUaH3UncsTIze4+cNiwtIuzVwhbobzYm7FRLjPWYJO8rNg0V4Z99RJLrgRHFsiQqoArz+YFUMAencEu0nPDv37fn/ZjxY0U8L5Pwojrvco+7CW8vpwmXxEV+KdtNNyDED1MxU22VFktcJ4VJuvzfYAm94ErFjzk1DiefTvYyj+KH/G0C7JcJCCQKGpNAv3Ag6JnYqtD5V2qJXiU2FeDUTSqNKNGYbr2g/cCp7eoykpo8Iu+oZTlLfoFY+p1wECO1yBChwFzSyo/atEj82tlhwi9Q0MyRcnUiNIcCwj/YKMcVxVLy1xWzC2iwiYTeRK0l+9haexYnoPXyy62W1G7a4LncSMBhwO3EzcUFaQ7EO6dIPesYIJwHl38ttIY6qa4mcyqDx4a603RqvAK+IJ4I0e1jO0Y4NIoqc4zDUz6xANmzVOV5re0zKjIVtxUOqYOPXb65orWkDDo/PIK+GmsppGxZHb5cPwzTmmXV1RS2ysr6jU3D0jwwMd3B5tuQhM5re3sEleHArD/hHKy92wjQW2BXDms4VGcMj0hP9r2BORhno6KKgw0hZOzYD/FU/YvZmRUQwRoH+rMfTccQ4jpK2iGawmY6786kKye6xSkIRAfIDCes= X-Forefront-Antispam-Report: CIP:66.129.239.14;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:p-exchfe-eqx-01.jnpr.net;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230025)(4636009)(346002)(396003)(376002)(136003)(39860400002)(451199018)(46966006)(40470700004)(36840700001)(81166007)(40480700001)(336012)(82740400003)(9686003)(36860700001)(70586007)(40460700003)(26005)(47076005)(7126003)(55016003)(186003)(6266002)(107886003)(2906002)(6916009)(316002)(54906003)(5660300002)(41300700001)(8676002)(4326008)(70206006)(7696005)(356005)(86362001)(82310400005)(8936002)(478600001)(36900700001);DIR:OUT;SFP:1102; X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Feb 2023 22:35:59.5456 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 1a167c9f-581c-4850-81a3-08db15ee563e X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4;Ip=[66.129.239.14];Helo=[p-exchfe-eqx-01.jnpr.net] X-MS-Exchange-CrossTenant-AuthSource: DM6NAM12FT043.eop-nam12.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH2PR05MB7096 X-Proofpoint-ORIG-GUID: QLnWy3qIOWny6Y0QP2635IGwA6RlgEQz X-Proofpoint-GUID: QLnWy3qIOWny6Y0QP2635IGwA6RlgEQz X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.219,Aquarius:18.0.930,Hydra:6.0.562,FMLib:17.11.170.22 definitions=2023-02-23_13,2023-02-23_01,2023-02-09_01 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 clxscore=1015 impostorscore=0 mlxscore=0 suspectscore=0 malwarescore=0 spamscore=0 bulkscore=0 priorityscore=1501 lowpriorityscore=0 phishscore=0 adultscore=0 mlxlogscore=999 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2212070000 definitions=main-2302230187 X-Rspamd-Queue-Id: 4PN7DB0Fdgz3nRG X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:22843, ipnet:67.231.152.0/24, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N Mark Millard wrote: > [External Email. Be cautious of content] > = > = > [Note for "how many separate bmake instances are in that log?": > I do not know how to tell how many submakes are run total. It > was with -j32 on the threadripper 1950X, if that is was you > were after.] You can get a clue from the number of directories being built - each will have its own instance of bmake. > > Per my last response, I'd be pretty sure MAKEOBJDIR is incorrect. > = > Which still leaves me experimenting to find a correct > reference. Do you know notation will always lead to the > same absolute path with the proper /usr/obj/BUILDs/*/usr/main-src/*.*/ > prefix ? (I've been showing just the main-amd64-nodbg-clang > and amd64.amd64 combination but there are many more.) I would question why you care. What is wrong with ${OBJTOP} ? Hmm, this does not look promising actually: grep '^OBJTOP' share/mk/*mk share/mk/bsd.obj.mk:OBJTOP?=3D ${MAKEOBJDIR} share/mk/bsd.obj.mk:OBJTOP?=3D ${.OBJDIR:S,${.CURDIR},,}${SRCTOP} share/mk/local.meta.sys.mk:OBJTOP:=3D ${OBJROOT}${TARGET_OBJ_SPEC} share/mk/local.meta.sys.mk:OBJTOP :=3D ${HOST_OBJTOP} share/mk/local.sys.mk:OBJTOP?=3D ${.OBJDIR:S,${.CURDIR},,}${SRCTOP} share/mk/src.sys.obj.mk:OBJTOP:=3D ${OBJROOT}${TARGET}.${TARGET_ARCH} share/mk/src.sys.obj.mk:OBJTOP:=3D ${OBJROOT:H} share/mk/src.sys.obj.mk:OBJTOP:=3D ${OBJROOT}${MACHINE}.${MACHINE_ARCH} share/mk/src.sys.obj.mk:OBJTOP:=3D ${OBJROOT:H} share/mk/src.sys.obj.mk:OBJTOP:=3D ${MAKEOBJDIRPREFIX}${SRCTOP} share/mk/src.sys.obj.mk:OBJTOP=3D ${SRCTOP} Without full context, apart from local.meta.sys.mk some of the above looks highly dubious In some respects the BSD build provides way too much flexibility. About 20 years ago at Juniper we found it untenable to continue allowing users 4 different options for the relationship between their srcs and objects. So we simply mandated: SRCTOP=3D ${SB}/src OBJROOT=3D ${SB}/obj/ OBJTOP=3D ${OBJROOT}/${MACHINE}/ MAKEOBJDIR=3D ${.CURDIR:S,${SRCTOP},${OBJTOP},} and life was better, but in a project like FreeBSD you cannot imposed your will that way ;-) > >>>>> .MAKE.META.IGNORE_PATHS+=3D ${OBJTOP}/tmp/ > >>>> > >>>> (Ignoring the variability of OBJTOP issue . . .) > >>>> > >>>> I do not expect that would work: ignoring things > >>>> it likely should not. > >>> > >>> Sure, but it may be useful as an experiment to ensure things are > >>> behaving as expected. > >> > >> As a test: > >> > >> .if ${.MAKE.LEVEL} =3D=3D 0 > >> .MAKE.META.IGNORE_PATHS+=3D ${MAKEOBJDIR:tA}/tmp/ > >> .MAKE.META.IGNORE_PATHS:=3D ${.MAKE.META.IGNORE_PATHS} > >> .endif > > > > Lose the .if ${.MAKE.LEVEL} =3D=3D 0 > > it is almost certainly keeping things from working as expected. > = > What do you want tested instead of MAKEOBJDIR ? I would expect you want ${OBJTOP} (assuming a sane value for OBJTOP ;-) > I'm taking a guess (no .MAKE.LEVEL use): Correct. > = > .MAKE.META.IGNORE_PATHS+=3D ${OBJTOP:tA}/tmp/ > .MAKE.META.IGNORE_PATHS:=3D ${.MAKE.META.IGNORE_PATHS:tA} You do not want to apply :tA to everything. .MAKE.META.IGNORE_PATHS+=3D ${OBJTOP}/tmp/ ${OBJTOP:tA}/tmp/ should be valid. > = > = > >> I still get things like: > >> > >> /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/sys/G= ENERIC-NODBG/modules/usr/main-src/sys/modules/zlib/x86.meta: 23: file '/us= r/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/tmp/legacy/us= r/sbin/realpath' is newer than the target... and is OBJTOP /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.am= d64 ? > >> Building /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.am= d64/sys/GENERIC-NODBG/modules/usr/main-src/sys/modules/zlib/x86 > > > > Because that will not be level 0 and so .MAKE.META.IGNORE_PATHS is not > > set. > = > I tried the above and I still get (picking to look for > tmp/legacy/usr/sbin/ln examples): > = > /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/sys/GENE= RIC-NODBG/modules/usr/main-src/sys/modules/aac/opt_scsi.h.meta: 22: file '= /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/tmp/legacy= /usr/sbin/ln' is newer than the target... Its a bit messy with kernels since there isn't a src directory associated with each (in FreeBSD anyway) but you could add the following to one of the makefiles that will be in play: .info ${.CURDIR .OBJDIR OBJTOP .MAKE.META.IGNORE_PATHS:L:@v@${.newline}$v=3D= ${$v}@} to help you see what is going on. It should then be easy to see whether OBJTOP is covered by .MAKE.META.IGNORE_PATHS From nobody Fri Feb 24 00:41:34 2023 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 4PNB0w4T1zz3t1FX for ; Fri, 24 Feb 2023 00:41:52 +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 4PNB0v74brz43Zb for ; Fri, 24 Feb 2023 00:41:51 +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=1677199310; bh=RDq012SObCTziGxCoAy/vaN1Lgw3L6x5rD3yzuR6t+M=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=bz+ll1cmFeClgi8uNWH0NEpowo/ndAaAOxB21UemnP42wrLrKpjrWoc7c3iyo5udeMmwdHCUkTU1ZvFm5Vb/UhObSBTci3ulLv0vJ8noLmpiG/2fqQBiy4d+pgJM39j1jlxHDWsdUnlSIMgwf/cK5zhOaDWvk8b0JlWZJc0OVAemdUE2NRmx1L1qebTrVqP1V40na8PAQaAHu3OJKuHoOVlIoAQ76DkEdsZLaHTp2NESdHTDrnDa17EiHmZiPeiQN0kn4rnVnZfrrLrMm3gLlSio3AX3dHsbkQW2cE5eliiCP2dbJeSCSDAvrd6rAQX5Ix51H1KlYD8tOX4N/bc3Zg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1677199310; bh=Q0kho9kjknxUk1OqxTzU2vMT7iKIQeERN1djz7tN8JA=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=uXq0qOdCZYf9GCIi7h9bZm4HoUuigOZ8v0UAjuPpPSKqTDK18AKVY6G0Xby73yzPRsdLPBM2GlJiv/nSMV3H0K3Fm9s6JQDJ6sRKuRdemGHLwzdYywGFkKcCO9ivyFjDK6NzxVvsF4dc0M4h5LGF69K8KYhrRnvMYuJvXkUEIvW0APR0a5M7Qr9bGqiIU1QmFWxgVVu2NK0EaFwiT5/OriySYIvN6uBSt9VWsLzfIZAvYvC9rbuRgr/YaFiFRQdUTxYCThdwwAQ0zmtIUVxwcVcsLJb4gk8MucFrP5vuL777PR1s3zmbv7K5z0yRzkdPZJ1j3Iib8ixgodApAsplUA== X-YMail-OSG: Q_M6kIYVM1lwF_tzRnlTwnqgdpc5gtY4RdqCClELs1iWP4mVybNwDP81MQi75Ty LFbuOE2i2hRketp._EH5nSe01VNG.B12c5b6MgzdWCT7nbqdfaIC_twixsppb7uxD2fTstWso4_b uvjOrNnxlhyrRUT_Bou2E8KsPQR.dIwr6zJyUWUVK9kPUSfVAZFFYwgcCNggz8hnknK5lH_LJSrC ombUHNtYeNpZys57ElR0VGOAKiJvmFrSb5EG8GAdONBvu4JDeNfm5R9Le5NvIcQUlj.R0ENNFaAP gBriiPkqzN1HY8UtXUop5ijVdG2YsTzd_FQTnDXRkHD2AjEIxl5oUumWfcDnsV5WqB8yqAPdOae2 KZ.UDruSc8FGj9TyN8dezAaNu42rbgI3w.TD2DV_rHn_ZcM5syj89p70cyGhtEZHRojY9884CyqV tpwE3ZGWd309dh5.x6SsdsnjTCcy_Bg_HTA92N7Vh7jjYYVIpOY6w0FG9zY9RPeFrSvtuORco6kV raMu3sJuSpOoesBZKociKyEaHo8CjYS8E3MoPDjXkbzWx5KlOCkemNdI1aPUvBC.PMNdyGWtlJbH 2pDnbqNvrAjpheKG.fJ6o5DV5VGeICEPdJHV2rqlktD9w3DW8xTSxY6kIHOtoTucK8EMWzQ9cLSH z4Tl18XYiGMLJbftVFCImgjU30layadqBKw2rmDi_D1bDqGQDiNRFBnOfCarrYOd7LkDLC7jaHRO Sep0mI9lTvTtE3v_bWQB0ZZ1r9fFHUzJ_Ry_kxrFeXcA9fp64y_82gZxyeJQCNLcRcnzyymCuz4Y XbzGmSWdFSIiOtrIj.I7RKOL15rvE5COGEzLXKrxGWVsGkYq4S5miKo_ZuNPwJJMnWBkX5eR4Nze 7Az8SpCIk29emIhps9iYD6lgKQhPVXr7cEamvNGuEsFOr977YgTeHFb9WLPeYgdftIcGw7CKoNkJ nS2rbePHq9snyKfwYrxqLkDfturfiROZ7SNrGwZXMSNo3VXCTSSP0lcfqso9a6Oddk.9VDCll9iG .E.dWsIQq6cUjjPQNkygrjnjKriIIcYTroS72Y6yF2mfuc_BbzFXfJ_VmdP9IkIUkMZ60.2AJGjo ftJejC8e0vgDyI0LFLPZUJx0VwiSTNSiLpkbcev.Qqhl645AJ3uxtAMCECcCwCqUD1AjMYiKeUWs R0JQcqjOBGKdy_fIoupYSsrhwi.u_8MBD3zOXXMT3sQViZJogOPMUXjZLdg6DDluqt1eenpWVSOe n_SB2i3ZL7uxNOfQG2J83zw95zhgNFgC1cxsOeeERmYZ.bArWgNDm_.Uieo_6vHoJrlvuJ4wrVP6 jIPR6F_uSmxnslIq1uMnbcnJtxwqHbVmXVcQLq98paHs4cQgso4M0x7hhDTs0vgTuzWd1Xat5kli kRNfx2.OSY0kagRuRMAQJ_1Fp_w3XGrJ7l2SLzbQ0xruKD98tlavSIuUr92nJ7SuPHuSxxb2tT2M KhZo1SrvjeGoCZnhMBVCulACbPs_U01kzElxoloELM8jv1ALs9arh_7cRabcRZKLizFNr5ty9uhI kIEmMrlVMeep5GNopCSewuWqWA0uP4lKn2TRSzHgYJ2v6AkttUm3SkrXTUy1DIvl1XRUNSKPJZwC F2fJ8vxVCboIHNlDq.mD9f5yfINmI.ftQ03DxPY.N8HCHOnFoNKRQJ5PoZ0bNtjvTbud8gxYvWpL evWffZQ8SWf6ADW6k.Vt8hKvnmNb6wjs9ht3t_Ut8ui5JOzsAXNdPGuVqoqg4t3kGR_yticR6YoU 3lV7abZSO0nneeFrrdSi3RjCRXfx5GBqYVh5Un0uInGQtKQjawNkZ31OziIiPxBYaUkRHArIxhDE G22xQR2512QHvNZ2TzGlXKJMC67V7FOwHiFIOvLIZlvFI1D3ZO7NanS5xKz72PglcscDCnLNCqlJ cEjMM7K59AgaZnb1mw6mewHhOmsNs4hQ4lboAh1wORNSwl4G01UEh_DUC5RjvLO7PE_OxGHgqSj6 Pmw1PWuYQwRLUEvPeBo4Zlmet_L1bRb0iXrsNehtk0gW_LOZ9_w.9VJic18L9rKzGnChNts94vS8 dazcLaVeJHJusOgt5SNkWxGSgouI9ECwyEkZMWJQVRgcxeWX5HDPKPqkSxHWuMpTXRuMyfNc1KNx wCHXHhEC8iChchiPnJRPne6Z6_TY0A6zuGiB.Qfi1EMH0KN7.H2Q.a79vGe1Yf3x0ORz0kVhkSXW XbtW6vEDFKSwpegZpOhhXV8e8hTf96EGHbS2DGeDkPuO6yczp.7MyDb9V1riNMd7mGTSer0fUYOv GxJXK6w-- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic317.consmr.mail.gq1.yahoo.com with HTTP; Fri, 24 Feb 2023 00:41:50 +0000 Received: by hermes--production-bf1-57c96c66f6-hmvtp (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 1d043bcb474d68ce3a00571d0b78ee2b; Fri, 24 Feb 2023 00:41:46 +0000 (UTC) Content-Type: text/plain; charset=us-ascii 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 Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.400.51.1.1\)) Subject: Re: FYI: Why META_MODE rebuilds so much for building again after installworld (no source changes) From: Mark Millard In-Reply-To: <30.1677189836@kaos.jnpr.net> Date: Thu, 23 Feb 2023 16:41:34 -0800 Cc: Bryan Drewery , Current FreeBSD , Peter Content-Transfer-Encoding: quoted-printable Message-Id: <1B5FCF8A-0DFD-4246-8464-65A44A40529F@yahoo.com> References: <3345EBA5-A09C-4E3F-B94D-39F57F56BDBB@yahoo.com> <73088.1611797582@kaos.jnpr.net> <10819.1677108389@kaos.jnpr.net> <76FA98EF-6184-4D7E-A01F-0EE8117D0D10@yahoo.com> <29887.1677115125@kaos.jnpr.net> <27790339-240F-4C97-97C7-38AFD8DE03D5@yahoo.com> <7FB6F619-6E71-4075-8A6C-573564371DD5@yahoo.com> <2655.1677134606@kaos.jnpr.net> <242BB478-B2FE-4BCC-A56E-098F3FEB3EE1@yahoo.com> <42586.1677183334@kaos.jnpr.net> <30.1677189836@kaos.jnpr.net> To: "Simon J. Gerraty" X-Mailer: Apple Mail (2.3731.400.51.1.1) X-Rspamd-Queue-Id: 4PNB0v74brz43Zb X-Spamd-Bar: ---- 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-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N On Feb 23, 2023, at 14:03, Simon J. Gerraty wrote: Simplifying context . . . . . . > As I mentioned previously, there is no variablity of OBJTOP within the > context of a single make instance - at least not once it starts = running > targets. >=20 >> . . . >=20 > .MAKE.META.IGNORE_PATHS +=3D ${OBJTOP}/tmp/legacy/usr I'll use that definition line for the below. > should result in nothing under ${OBJTOP}/tmp/legacy/usr causing a = target > to be out of date - just because it is newer. I'll ignore there that that is skipping too much and just show what happens for the 2nd buildkernel of 2 in a row when I use that exact line for both make runs. First counts of the "is newer than" lines, counting separate program names separately: # cat = /usr/obj/BUILDs/main-amd64-nodbg-clang/sys-typescripts/typescript-make-amd= 64-nodbg-clang-amd64-host-2023-02-23:16:15:18 | grep "is newer than the = target" | sed - e "s@^.*: file '@file '@" | sort | uniq -c | sort -rn | more 2553 file = '/usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/tmp/legac= y/usr/sbin/realpath' is newer than the target... 1001 file = '/usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/tmp/legac= y/usr/sbin/ln' is newer than the target... Thousands of rebuilt things based on: . . ./tmp/legacy/usr/sbin/realpath . . ./tmp/legacy/usr/sbin/ln It appears that buildkernel does not use an OBJTOP definition that references: /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64 in my context. For reference of Build lines paired with a few of those "is newer than" lines: First realpath: # grep -A1 "tmp/legacy/usr/sbin/realpath\>" = /usr/obj/BUILDs/main-amd64-nodbg-clang/sys-typescripts/typescript-make-amd= 64-nodbg-clang-amd64-host-2023-02-23:16:15:18 | more = /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/sys/GENERI= C-NODBG/modules/usr/main-src/sys/modules/aac/machine.meta: 23: file = '/usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/tmp/legac= y/usr/sbin/realpath' is newer than the target... Building = /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/sys/GENERI= C-NODBG/modules/usr/main-src/sys/modules/aac/machine -- = /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/sys/GENERI= C-NODBG/modules/usr/main-src/sys/modules/aac/x86.meta: 23: file = '/usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/tmp/legac= y/usr/sbin/realpath' is newer than the target... Building = /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/sys/GENERI= C-NODBG/modules/usr/main-src/sys/modules/aac/x86 -- = /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/sys/GENERI= C-NODBG/modules/usr/main-src/sys/modules/aac/i386.meta: 23: file = '/usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/tmp/legac= y/usr/sbin/realpath' is newer than the target... Building = /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/sys/GENERI= C-NODBG/modules/usr/main-src/sys/modules/aac/i386 -- = /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/sys/GENERI= C-NODBG/modules/usr/main-src/sys/modules/aacraid/machine.meta: 23: file = '/usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/tmp/legac= y/usr/sbin/realpath' is newer than the target... Building = /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/sys/GENERI= C-NODBG/modules/usr/main-src/sys/modules/aacraid/machine -- = /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/sys/GENERI= C-NODBG/modules/usr/main-src/sys/modules/aacraid/x86.meta: 23: file = '/usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/tmp/legac= y/usr/sbin/realpath' is newer than the target... Building = /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/sys/GENERI= C-NODBG/modules/usr/main-src/sys/modules/aacraid/x86 -- . . . Then for ln: # grep -A1 "tmp/legacy/usr/sbin/ln\>" = /usr/obj/BUILDs/main-amd64-nodbg-clang/sys-typescripts/typescript-make-amd= 64-nodbg-clang-amd64-host-2023-02-23:16:15:18 | more = /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/sys/GENERI= C-NODBG/modules/usr/main-src/sys/modules/aac/opt_scsi.h.meta: 12: file = '/usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/tmp/legac= y/usr/sbin/ln' is newer than the target... Building = /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/sys/GENERI= C-NODBG/modules/usr/main-src/sys/modules/aac/opt_scsi.h = /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/sys/GENERI= C-NODBG/modules/usr/main-src/sys/modules/aac/opt_cam.h.meta: 12: file = '/usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/tmp/legac= y/usr/sbin/ln' is newer than the target... Building = /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/sys/GENERI= C-NODBG/modules/usr/main-src/sys/modules/aac/opt_cam.h = /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/sys/GENERI= C-NODBG/modules/usr/main-src/sys/modules/aac/opt_aac.h.meta: 12: file = '/usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/tmp/legac= y/usr/sbin/ln' is newer than the target... Building = /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/sys/GENERI= C-NODBG/modules/usr/main-src/sys/modules/aac/opt_aac.h -- = /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/sys/GENERI= C-NODBG/modules/usr/main-src/sys/modules/aacraid/opt_scsi.h.meta: 12: = file = '/usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/tmp/legac= y/usr/sbin/ln' is newer than the target... Building = /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/sys/GENERI= C-NODBG/modules/usr/main-src/sys/modules/aacraid/opt_scsi.h = /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/sys/GENERI= C-NODBG/modules/usr/main-src/sys/modules/aacraid/opt_cam.h.meta: 12: = file = '/usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/tmp/legac= y/usr/sbin/ln' is newer than the target... Building = /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/sys/GENERI= C-NODBG/modules/usr/main-src/sys/modules/aacraid/opt_cam.h = /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/sys/GENERI= C-NODBG/modules/usr/main-src/sys/modules/aacraid/opt_aacraid.h.meta: 12: = file = '/usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/tmp/legac= y/usr/sbin/ln' is newer than the target... Building = /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/sys/GENERI= C-NODBG/modules/usr/main-src/sys/modules/aacraid/opt_aacraid.h -- = /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/sys/GENERI= C-NODBG/modules/usr/main-src/sys/modules/acpi/acpi_asus/opt_acpi.h.meta: = 12: file = '/usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/tmp/legac= y/usr/sbin/ln' is newer than the target... Building = /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/sys/GENERI= C-NODBG/modules/usr/main-src/sys/modules/acpi/acpi_asus/opt_acpi.h = /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/sys/GENERI= C-NODBG/modules/usr/main-src/sys/modules/acpi/acpi_asus/opt_ddb.h.meta: = 12: file = '/usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/tmp/legac= y/usr/sbin/ln' is newer than the target... Building = /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/sys/GENERI= C-NODBG/modules/usr/main-src/sys/modules/acpi/acpi_asus/opt_ddb.h -- . . . I've still no clue of a notation that avoids this for my choice to use personal MAKEOBJDIRPREFIX paths: amd64 context: # grep MAKEOBJDIRPREFIX make-*.sh = make-13S-amd64-dbg-clang.amd64-host.sh:MAKEOBJDIRPREFIX=3D"/usr/obj/BUILDs= /13S-amd64-dbg-clang" \ = make-13S-amd64-dbg-gccxtc.amd64-host.sh:MAKEOBJDIRPREFIX=3D"/usr/obj/BUILD= s/13S-amd64-dbg-gccxtc" \ = make-13S-amd64-nodbg-clang.amd64-host.sh:MAKEOBJDIRPREFIX=3D"/usr/obj/BUIL= Ds/13S-amd64-nodbg-clang" \ = make-13S-amd64-nodbg-gccxtc.amd64-host.sh:MAKEOBJDIRPREFIX=3D"/usr/obj/BUI= LDs/13S-amd64-nodbg-gccxtc" \ = make-13_0R-amd64-dbg-clang.amd64-host.sh:MAKEOBJDIRPREFIX=3D"/usr/obj/BUIL= Ds/13_0R-amd64-dbg-clang" \ = make-13_0R-amd64-nodbg-clang.amd64-host.sh:MAKEOBJDIRPREFIX=3D"/usr/obj/BU= ILDs/13_0R-amd64-nodbg-clang" \ = make-13_1R-amd64-dbg-clang.amd64-host.sh:MAKEOBJDIRPREFIX=3D"/usr/obj/BUIL= Ds/13_1R-amd64-dbg-clang" \ = make-13_1R-amd64-dbg-gccxtc.amd64-host.sh:MAKEOBJDIRPREFIX=3D"/usr/obj/BUI= LDs/13_1R-amd64-dbg-gccxtc" \ = make-13_1R-amd64-nodbg-clang.amd64-host.sh:MAKEOBJDIRPREFIX=3D"/usr/obj/BU= ILDs/13_1R-amd64-nodbg-clang" \ = make-13_1R-amd64-nodbg-gccxtc.amd64-host.sh:MAKEOBJDIRPREFIX=3D"/usr/obj/B= UILDs/13_1R-amd64-nodbg-gccxtc" \ = make-alt-main-amd64-nodbg-clang-alt.amd64-host.sh:MAKEOBJDIRPREFIX=3D"/usr= /obj/BUILDs/main-amd64-nodbg-clang-alt" \ = make-main-amd64-dbg-clang.amd64-host.sh:MAKEOBJDIRPREFIX=3D"/usr/obj/BUILD= s/main-amd64-dbg-clang" \ = make-main-amd64-dbg-gccxtc.amd64-host.sh:MAKEOBJDIRPREFIX=3D"/usr/obj/BUIL= Ds/main-amd64-dbg-gccxtc" \ = make-main-amd64-nodbg-clang-alt.amd64-host.sh:MAKEOBJDIRPREFIX=3D"/usr/obj= /BUILDs/main-amd64-nodbg-clang-alt" \ = make-main-amd64-nodbg-clang.amd64-host.sh:MAKEOBJDIRPREFIX=3D"/usr/obj/BUI= LDs/main-amd64-nodbg-clang" \ = make-main-amd64-nodbg-gccxtc.amd64-host.sh:MAKEOBJDIRPREFIX=3D"/usr/obj/BU= ILDs/main-amd64-nodbg-gccxtc" \ aarch64 context (and armv7): # grep MAKEOBJDIRPREFIX make-*.sh = make-13S-CA53-dbg-clang.aarch64-host.sh:MAKEOBJDIRPREFIX=3D"/usr/obj/BUILD= s/13S-CA53-dbg-clang" \ = make-13S-CA53-nodbg-clang.aarch64-host.sh:MAKEOBJDIRPREFIX=3D"/usr/obj/BUI= LDs/13S-CA53-nodbg-clang" \ = make-13S-CA7-dbg-clang.aarch64-host.sh:MAKEOBJDIRPREFIX=3D"/usr/obj/BUILDs= /13S-CA7-dbg-clang" \ = make-13S-CA7-nodbg-clang.aarch64-host.sh:MAKEOBJDIRPREFIX=3D"/usr/obj/BUIL= Ds/13S-CA7-nodbg-clang" \ = make-13S-CA72-dbg-clang.aarch64-host.sh:MAKEOBJDIRPREFIX=3D"/usr/obj/BUILD= s/13S-CA72-dbg-clang" \ = make-13S-CA72-nodbg-clang.aarch64-host.sh:MAKEOBJDIRPREFIX=3D"/usr/obj/BUI= LDs/13S-CA72-nodbg-clang" \ = make-13_0R-CA53-nodbg-clang.aarch64-host.sh:MAKEOBJDIRPREFIX=3D"/usr/obj/B= UILDs/13_0R-CA53-nodbg-clang" \ = make-13_0R-CA7-nodbg-clang-alt.aarch64-host.sh:MAKEOBJDIRPREFIX=3D"/usr/ob= j/BUILDs/13_0R-CA7-nodbg-clang-alt" \ = make-13_0R-CA7-nodbg-clang.aarch64-host.sh:MAKEOBJDIRPREFIX=3D"/usr/obj/BU= ILDs/13_0R-CA7-nodbg-clang" \ = make-13_0R-CA72-dbg-clang.aarch64-host.sh:MAKEOBJDIRPREFIX=3D"/usr/obj/BUI= LDs/13_0R-CA72-dbg-clang" \ = make-13_0R-CA72-nodbg-clang-alt.aarch64-host.sh:MAKEOBJDIRPREFIX=3D"/usr/o= bj/BUILDs/13_0R-CA72-nodbg-clang-alt" \ = make-13_0R-CA72-nodbg-clang.aarch64-host.sh:MAKEOBJDIRPREFIX=3D"/usr/obj/B= UILDs/13_0R-CA72-nodbg-clang" \ = make-13_1R-CA53-nodbg-clang.aarch64-host.sh:MAKEOBJDIRPREFIX=3D"/usr/obj/B= UILDs/13_1R-CA53-nodbg-clang" \ = make-13_1R-CA7-nodbg-clang-alt.aarch64-host.sh:MAKEOBJDIRPREFIX=3D"/usr/ob= j/BUILDs/13_1R-CA7-nodbg-clang-alt" \ = make-13_1R-CA7-nodbg-clang.aarch64-host.sh:MAKEOBJDIRPREFIX=3D"/usr/obj/BU= ILDs/13_1R-CA7-nodbg-clang" \ = make-13_1R-CA72-dbg-clang.aarch64-host.sh:MAKEOBJDIRPREFIX=3D"/usr/obj/BUI= LDs/13_1R-CA72-dbg-clang" \ = make-13_1R-CA72-nodbg-clang-alt.aarch64-host.sh:MAKEOBJDIRPREFIX=3D"/usr/o= bj/BUILDs/13_1R-CA72-nodbg-clang-alt" \ = make-13_1R-CA72-nodbg-clang.aarch64-host.sh:MAKEOBJDIRPREFIX=3D"/usr/obj/B= UILDs/13_1R-CA72-nodbg-clang" \ = make-alt-main-CA7-nodbg-clang-alt.aarch64-host.sh:MAKEOBJDIRPREFIX=3D"/usr= /obj/BUILDs/main-CA7-nodbg-clang-alt" \ = make-main-CA53-dbg-clang.aarch64-host.sh:MAKEOBJDIRPREFIX=3D"/usr/obj/BUIL= Ds/main-CA53-dbg-clang" \ = make-main-CA53-nodbg-clang-alt.aarch64-host.sh:MAKEOBJDIRPREFIX=3D"/usr/ob= j/BUILDs/main-CA53-nodbg-clang-alt" \ = make-main-CA53-nodbg-clang.aarch64-host.sh:MAKEOBJDIRPREFIX=3D"/usr/obj/BU= ILDs/main-CA53-nodbg-clang" \ = make-main-CA7-dbg-clang.aarch64-host.sh:MAKEOBJDIRPREFIX=3D"/usr/obj/BUILD= s/main-CA7-dbg-clang" \ = make-main-CA7-nodbg-clang-alt.aarch64-host.sh:MAKEOBJDIRPREFIX=3D"/usr/obj= /BUILDs/main-CA7-nodbg-clang-alt" \ = make-main-CA7-nodbg-clang.aarch64-host.sh:MAKEOBJDIRPREFIX=3D"/usr/obj/BUI= LDs/main-CA7-nodbg-clang" \ = make-main-CA72-dbg-clang.aarch64-host.sh:MAKEOBJDIRPREFIX=3D"/usr/obj/BUIL= Ds/main-CA72-dbg-clang" \ = make-main-CA72-dbg-gccxtc.aarch64-host.sh:MAKEOBJDIRPREFIX=3D"/usr/obj/BUI= LDs/main-CA72-dbg-gccxtc" \ = make-main-CA72-nodbg-clang-alt.aarch64-host.sh:MAKEOBJDIRPREFIX=3D"/usr/ob= j/BUILDs/main-CA72-nodbg-clang-alt" \ = make-main-CA72-nodbg-clang.aarch64-host.sh:MAKEOBJDIRPREFIX=3D"/usr/obj/BU= ILDs/main-CA72-nodbg-clang" \ = make-main-CA72-nodbg-gccxtc.aarch64-host.sh:MAKEOBJDIRPREFIX=3D"/usr/obj/B= UILDs/main-CA72-nodbg-gccxtc" \ =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Fri Feb 24 01:42:19 2023 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 4PNCNR2GQ9z3t43d for ; Fri, 24 Feb 2023 01:43:51 +0000 (UTC) (envelope-from sjg@juniper.net) Received: from mx0b-00273201.pphosted.com (mx0b-00273201.pphosted.com [67.231.152.164]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.pphosted.com", Issuer "Thawte RSA CA 2018" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4PNCNQ6bKVz49qb; Fri, 24 Feb 2023 01:43:50 +0000 (UTC) (envelope-from sjg@juniper.net) Authentication-Results: mx1.freebsd.org; none Received: from pps.filterd (m0108162.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 31O0P819022643; Thu, 23 Feb 2023 17:43:27 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=to : cc : subject : in-reply-to : references : from : mime-version : content-type : content-id : content-transfer-encoding : date : message-id; s=PPS1017; bh=tvMU0fL/SeS6+RUDUTkKq1SwHRb7bkT+t++QDl0A3rk=; b=xfx1hNm3NoyGizCp43XcJFMSx6T/yQp/4FGnyE/dS4NaRrJdZOW4+h2Qa18fjZRBAmA2 M0MShICPGUm3rtLGHRwLDvlXHCpuIBemBr/lzP09AIekx+ihfIum5/54I/ann7thao1l vqGmfS6pvDCDDHsHKuIgh5GvbW53mvdV1iNcZc7sYZn8DPCn25+G0uky0x+wf1ZnYMvv /b0zojc0tHG8HUhCI/yTTSfqJtwRhZn3MFj+t/1XO4K+wYFqoZh6ByAiMetVUi7cLMGt RCSpw2xWRDvBhXduTPEHthzzWB2B2s7Pmf1u4CvLau34XZBozGnybO3GPg2i3ldlUjJL JA== Received: from co1pr02cu001-vft-obe.outbound.protection.outlook.com (mail-westus2azlp17011011.outbound.protection.outlook.com [40.93.10.11]) by mx0b-00273201.pphosted.com (PPS) with ESMTPS id 3nxjp1r3xc-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 23 Feb 2023 17:43:27 -0800 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=eFc/IlF+eY6Eub1Jnt7mN3nRIDTKdNuhC1eePK6/ann6/eB1V55ALXC82UjrHCmnczVF1JRFbc69L/rhRD0RFvu2kWRBymXrlGh/jfhiATlQV50xQrzJ3/OpyZAuPfDkrdUm80ASZcVN3+k43hg9VxvV8k3KkApoZrxVCF9zvMZ+/cHIit8/JmWQYzXRSMTc0m2SR7RteVsRcGa5ZcAzjFwzdhdKM2Agtf3mfnGwaq5CqAsU8N/XNSabyDVReKTtNPYV16B8a5Z+SLVCpooIhVrK7Wwo2mNUlp2ov/vNxXahgVR5cgKh6oVWnICwuhtVy6gLeShM6SKCJ5JCGAxyag== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=tvMU0fL/SeS6+RUDUTkKq1SwHRb7bkT+t++QDl0A3rk=; b=LcbNHqpIPmf24bdxnx3CQaP92CYzjhUnxS4GVeub43hUdS+izjHPeBvBtFqNPcKh/6t6KpOU8ivQb/Dr8AKnFVvB2nl0HehtbWW0LFf9Z+5MxoMRl9eeH2hWi2qN23PZ+tV1BMUVeOqhkPcVnzkDY60WTtZVHxgzCfb1TftmnUDkJ4LnAo31tn0t4/I3nE3O32LUwoWxDPT+tZ2edFZCnlZUhlElpqwNrSamoytPtGbYwuny+AafU1/nD9MY/UMlSg/wi1L/x9r38JilxkPvEN6qyRBRzsB4+nalN9GZto/jXnd25N8xgtMe+qy9MUaSP4NV3v6eN3rmypTIxrL9Sg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=softfail (sender ip is 66.129.239.15) smtp.rcpttodomain=yahoo.com smtp.mailfrom=juniper.net; dmarc=fail (p=reject sp=reject pct=100) action=oreject header.from=juniper.net; dkim=none (message not signed); arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=tvMU0fL/SeS6+RUDUTkKq1SwHRb7bkT+t++QDl0A3rk=; b=CdecwAfBnC427dNXr0gJ8FD1fR4cxjJCjFFoSr+S8o4p9dPmKnJzfv4c7ogQDAAVnVqd+E4wTT5rvzfLuprUSpi1nmKHmFsWzsr9I7+gEmgx0RasSFcnSgjJDKq5wZcwzK+I4d68H4dWICHLBHWUEpQb9bx4LPMWtBQuZXu2aAw= Received: from MW3PR06CA0011.namprd06.prod.outlook.com (2603:10b6:303:2a::16) by BYAPR05MB6037.namprd05.prod.outlook.com (2603:10b6:a03:d9::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6134.21; Fri, 24 Feb 2023 01:43:21 +0000 Received: from MW2NAM12FT105.eop-nam12.prod.protection.outlook.com (2603:10b6:303:2a:cafe::3b) by MW3PR06CA0011.outlook.office365.com (2603:10b6:303:2a::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6134.24 via Frontend Transport; Fri, 24 Feb 2023 01:43:20 +0000 X-MS-Exchange-Authentication-Results: spf=softfail (sender IP is 66.129.239.15) smtp.mailfrom=juniper.net; dkim=none (message not signed) header.d=none;dmarc=fail action=oreject header.from=juniper.net; Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.15 as permitted sender) Received: from p-exchfe-eqx-02.jnpr.net (66.129.239.15) by MW2NAM12FT105.mail.protection.outlook.com (10.13.181.69) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6156.7 via Frontend Transport; Fri, 24 Feb 2023 01:43:20 +0000 Received: from p-exchbe-eqx-02.jnpr.net (10.104.9.15) by p-exchfe-eqx-02.jnpr.net (10.104.9.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.30; Thu, 23 Feb 2023 19:43:20 -0600 Received: from p-exchbe-eqx-01.jnpr.net (10.104.9.14) by p-exchbe-eqx-02.jnpr.net (10.104.9.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.30; Thu, 23 Feb 2023 19:43:19 -0600 Received: from p-mailhub01.juniper.net (10.104.20.6) by p-exchbe-eqx-01.jnpr.net (10.104.9.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.30 via Frontend Transport; Thu, 23 Feb 2023 19:43:19 -0600 Received: from kaos.jnpr.net (kaos.jnpr.net [172.23.255.201]) by p-mailhub01.juniper.net (8.14.4/8.11.3) with ESMTP id 31O1hImm027968; Thu, 23 Feb 2023 17:43:19 -0800 (envelope-from sjg@juniper.net) Received: by kaos.jnpr.net (Postfix, from userid 1377) id 675E02112C; Thu, 23 Feb 2023 17:42:19 -0800 (PST) Received: from kaos.jnpr.net (localhost [127.0.0.1]) by kaos.jnpr.net (Postfix) with ESMTP id 6434D21289; Thu, 23 Feb 2023 17:42:19 -0800 (PST) To: Mark Millard CC: Bryan Drewery , Current FreeBSD , Peter , Subject: Re: FYI: Why META_MODE rebuilds so much for building again after installworld (no source changes) In-Reply-To: <1B5FCF8A-0DFD-4246-8464-65A44A40529F@yahoo.com> References: <3345EBA5-A09C-4E3F-B94D-39F57F56BDBB@yahoo.com> <73088.1611797582@kaos.jnpr.net> <10819.1677108389@kaos.jnpr.net> <76FA98EF-6184-4D7E-A01F-0EE8117D0D10@yahoo.com> <29887.1677115125@kaos.jnpr.net> <27790339-240F-4C97-97C7-38AFD8DE03D5@yahoo.com> <7FB6F619-6E71-4075-8A6C-573564371DD5@yahoo.com> <2655.1677134606@kaos.jnpr.net> <242BB478-B2FE-4BCC-A56E-098F3FEB3EE1@yahoo.com> <42586.1677183334@kaos.jnpr.net> <30.1677189836@kaos.jnpr.net> <1B5FCF8A-0DFD-4246-8464-65A44A40529F@yahoo.com> Comments: In-reply-to: Mark Millard message dated "Thu, 23 Feb 2023 16:41:34 -0800." From: "Simon J. Gerraty" X-Mailer: MH-E 8.6+git; nmh 1.7.1; GNU Emacs 28.1 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 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <89701.1677202939.1@kaos.jnpr.net> Content-Transfer-Encoding: quoted-printable Date: Thu, 23 Feb 2023 17:42:19 -0800 Message-ID: <93460.1677202939@kaos.jnpr.net> X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: MW2NAM12FT105:EE_|BYAPR05MB6037:EE_ X-MS-Office365-Filtering-Correlation-Id: bbbdab11-72a4-4b05-e79d-08db16088268 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: Ng+xvV/TVK3vTF9yf89djf+MwmHbxYY+fcvPkt/bNnGyi2pwvbyRdYYDcQIhBoJCyHUxX73qgbCPlM5WikL4CW3c7FoXtu244POdSuMHAKyt34RWJfCC+W7R7vnBFjgKsZbVyxp9+VFJ7A26Thejoz7cwfy9kUOJ1ujT/ATyXP2tq5RrsQKErxlaWu2a8XUArVHGIQ11HjdiKxnLz2wiNbSgclLbP66qFRQhVAzdQAjQYLyYEavNZzBKhp6g/crKg1UMv95ko2bbio2UB4Dtyl8q0pxrVJaqJULLRAxLlVQdEiSk5XROC2D8vnkXdwJl4aOh1r6FRFM1InGu/hvymqMy+ICx1HQIcu95i3CDwLujlLJso8hHnqqnXj0hrelbZudmEmU1+mAUkYRmERcQGTwFZkCAm82bSItqjt5en/5HtuOWntYb06oQl/UnmcldBuuX26zaahzoDjLFUlRJ6OZpi/QZ/oti5c4xDVm+GWfAuRnVLZ4e/K3bPW67lSTTgv0iV4W+JZ2vHGYyZC3Id+3/1dbpSCkvZv2vsLumMGXLHB+9w1DodP0JMCHjvYfjYSNuYnAKSD90BCdfSDG0IvGnnR5jEnZqBY9wnNfgPge4XrcBbx86ZS1IdxCoGzymykt1wcOCVKg60HFms/1xbIM2k0Un1d2u90qAG4ahAbR4LsDkHlA28LGA0Ee5N2sR4I6D0e4kOUo5imZorFveLT5hJzcOrEiytV3lKx4em3E= X-Forefront-Antispam-Report: CIP:66.129.239.15;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:p-exchfe-eqx-02.jnpr.net;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230025)(4636009)(136003)(376002)(346002)(39860400002)(396003)(451199018)(40470700004)(46966006)(36840700001)(40460700003)(70586007)(54906003)(70206006)(83380400001)(8676002)(41300700001)(8936002)(316002)(5660300002)(4326008)(6916009)(107886003)(7126003)(9686003)(186003)(6266002)(47076005)(26005)(478600001)(336012)(356005)(55016003)(82310400005)(40480700001)(2906002)(82740400003)(36860700001)(81166007)(7696005)(86362001)(36900700001);DIR:OUT;SFP:1102; X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 24 Feb 2023 01:43:20.6050 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: bbbdab11-72a4-4b05-e79d-08db16088268 X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4;Ip=[66.129.239.15];Helo=[p-exchfe-eqx-02.jnpr.net] X-MS-Exchange-CrossTenant-AuthSource: MW2NAM12FT105.eop-nam12.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR05MB6037 X-Proofpoint-GUID: x5ip88nUAgVnKMPiZnlLCZlrcahXWyFH X-Proofpoint-ORIG-GUID: x5ip88nUAgVnKMPiZnlLCZlrcahXWyFH X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.219,Aquarius:18.0.930,Hydra:6.0.562,FMLib:17.11.170.22 definitions=2023-02-23_15,2023-02-23_01,2023-02-09_01 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 bulkscore=0 suspectscore=0 impostorscore=0 mlxscore=0 malwarescore=0 spamscore=0 phishscore=0 mlxlogscore=999 clxscore=1015 adultscore=0 priorityscore=1501 lowpriorityscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2212070000 definitions=main-2302240010 X-Rspamd-Queue-Id: 4PNCNQ6bKVz49qb X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:22843, ipnet:67.231.152.0/24, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N Mark Millard wrote: > Simplifying context . . . > . . . > > As I mentioned previously, there is no variablity of OBJTOP within the > > context of a single make instance - at least not once it starts runnin= g > > targets. > > > >> . . . > > > > .MAKE.META.IGNORE_PATHS +=3D ${OBJTOP}/tmp/legacy/usr > = > I'll use that definition line for the below. Ok. > > should result in nothing under ${OBJTOP}/tmp/legacy/usr causing a targ= et > > to be out of date - just because it is newer. > = > I'll ignore there that that is skipping too much > and just show what happens for the 2nd buildkernel > of 2 in a row when I use that exact line for both > make runs. > = > First counts of the "is newer than" lines, counting > separate program names separately: > = > # cat /usr/obj/BUILDs/main-amd64-nodbg-clang/sys-typescripts/typescript-= make-amd64-nodbg-clang-amd64-host-2023-02-23:16:15:18 | grep "is newer tha= n the target" | sed - > e "s@^.*: file '@file '@" | sort | uniq -c | sort -rn | more > 2553 file '/usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd= 64/tmp/legacy/usr/sbin/realpath' is newer than the target... > 1001 file '/usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd= 64/tmp/legacy/usr/sbin/ln' is newer than the target... > = It is of course critical to know what OBJDIR is at this point. also can you show me the line in the meta file that is matching. If you add the .info line I suggested in kern.mk or kmod.mk you should get some useful info. > Thousands of rebuilt things based on: > = > . . ./tmp/legacy/usr/sbin/realpath > . . ./tmp/legacy/usr/sbin/ln > = > It appears that buildkernel does not use an OBJTOP definition > that references: It is possible it does not have a "normal" value for it. Kernel builds start in the objdir so .CURDIR is actually under OBJTOP, so unless the makefiles have appropriate logic for that case, and depending on how OBJTOP is derrived, you may have a bogus value. The fix in that case would be the makefile setting OBJTOP. > = > /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64 > = > in my context. > = > For reference of Build lines paired with a few of those "is newer > than" lines: > = > = > I've still no clue of a notation that avoids this for > my choice to use personal MAKEOBJDIRPREFIX paths: That should work, looking at share/mk/src.sys.obj.mk though looks like you might get OBJROOT?=3D ${_default_makeobjdirprefix}${SRCTOP}/ which may not be valid for a kernel build. At least ${.OBJDIR} will not have that ${OBJROOT} as a prefix and some of the settings for OBJTOP look just wrong to me: OBJTOP:=3D ${OBJROOT:H} is the opposite of what the relationship b/w OBJROOT and OBJTOP are in DIRDEPS_BUILD but it looks like OBJTOP:=3D ${OBJROOT}${MACHINE}.${MACHINE_ARCH} is more likely to be used, but given the above default for OBJROOT that is unlikely to work for a kernel build. Looks like share/mk/src.sys.obj.mk grok's SB (the setup I/we use) so you can take control by setting SB and SB_OBJROOT to anything you like and it should be used for OBJROOT and presumably hence OBJTOP even for a kernel build. Though I normally use MAKEOBJDIR (similar to the way it is set in _default_makeobjdir), I don't know how well that works with legacy targets though - there's a lot of baked in assumptions about using MAKEOBJDIRPREFIX. Again that .info line I gave you would provide some useful clues. --sjg From nobody Fri Feb 24 03:31:07 2023 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 4PNFmW4mgZz3t97L for ; Fri, 24 Feb 2023 03:31:23 +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 4PNFmW1QxWz4LJp for ; Fri, 24 Feb 2023 03:31:22 +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=1677209481; bh=A11DecxRk4cmkeT/5Fo+Ht1ZNJhdXGJJ/7IXYb00czU=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=oJr8z6T/1BhmMutuuDg0NYsWSpmnSKSAqVlcT97cFAtLhc2PxAR2EHmL95xTN5Hsba8nxU9Yt30eYVgp55ntSE+wgcbcNYINy+b8IyIjm6Y0XdSIIyi6hiCqPg4X1j0+tdUWugeJMBD5rD6PR44GplvYE2N3ST6rdz5jWEmbwrwwBAxJxjIy7jh/6szu5Vt1NyOfotjlaqRIjtI8I5ie5Zd8o+K/tbikdio6pTCV3yzyaNgMCammwSVMHXcXhSB/XD6miZovms/gh9DTbqwIemJK4SWDHF+78pZuk9tKRZY+RWfvwyUtfLCUoaTta7QF9NL+07kgIktSB7UGIr8Twg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1677209481; bh=seEIUcj0Ic/rIxpD85sl/na19DREZwzaSw8T4vvkecu=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=EF1q+ItUtowT25B866zOmYiK/XfZlmWKCVEe5t0ApjR9BA3MylL44u3alfayzdRlclKRszURcOCM75z/hsen1568H3zXLWvxBTYAxUu6+85DyI2zNOz+lGAPUDyBC5NuGiQNw3FH/C2G1UGvQ0TF29P6H9S3VOui1rfPpqq1Gr6WD8hCUgQzlu1CtLKswbLPPCMMsse87leutBBIrBPYMHvyeRMMtM3gu9nuMPkijTuiKgYbeB+HGy/+O7yqyRKqqTTXSkFH/4M9k9ZRQ0rAzt1DRhfbDx2fOtzaNmjd7EAyC8sXgC8HLbbjSoTrJCnVNr+Y1I6BBuVbTlZZH8t4Pg== X-YMail-OSG: JB6MM8kVM1nVSvOmZt6elWOSN44mAKoWdj0pOsPtlZzkZiRnJPeJXupbScxFqKi uLl1xvfHJY0ShepdMFP8pIFS77Wtp3pKk8JgvE.aX9i7uxuyuPtfqbf9HXxz8IMU1iYZi7bYI4fA J8fhC8MFKl.Cplup9cdpcH7QeQ242V4_hHGzBebKnDaIV6VlnBJ.5ZOjjzCyQq8uymUlbmyccCoR WfkObUFnTzZ02yb3.o6NhkFP067TDFRakNwpHcoGf9BjXthrHhdkvJ.Z_o2mxpqGbX..jXh7iZr5 gIkF7ZccYLb_ElUSHk_WN.ZMI3MAFo.HnEF9rgJfk5LT16CFh.6iUcjX70hBzagNvZWV84X5E0iU .3euvAgI9H_9bMdlTmToc2dlp0_dimuP2lKAUH79ILYKhOaIRfQ_bEsNv2naU5Eo1BY0zru4iu2S fV1PaqAwHka7pKLVFNEOi4E0Aq0Tf0DF8v3g29qh_10zCS_Ga0Gqvm1ktUKNSAiYYD3PJrdcmS.p bk2VFqih2WwMGHqjcCI3Lh_oxDxMJ8O1rrXIbEAebCkS.mmA_TMQsQVIR7ZoI_rAN9Feb1ebFzHr 2BYilL_7SUIvOih6ThYBYo6n1.n6XMvzGKLEhR94MddUI2IO_la.bpG9_2dxOfRj4hSPLKsz4A.C crhaa_eADx3X2ZEh1r.IKhB3S8m20Jjtu8UBIY0e9NRgOS11XYk0DaSZvSKrkk_5bd27V8MSGL9h xCv_MWLh1YQc5UolXNTg8PK2LVUirUy5ezz6GnUAnAP8GSxgDNbBVyHiM6pYXIQQifoqbUVlXmHW QpdRub5GOQbuh8MgP2Zf6bmgoHSFAFkHXUSJdIPToOJE8SeC41V7VlFIA1Br2nFwEG35qXc6FP8Q Pk7gFp15Ox6RubioVMzBmpoidih3V3Eg6KuyGHWVlPpFbbiaqJIsKxpEONWlgIEYG4jSq8vWY3ZR im9nOZoAJ9GeeCLkgtWkGjsWQBPpsB9TfHdyOg1z4cxycr5srPsCkf._5xuEMFLInrymcWkpTiVx HH3QtsF_wNBdkJ7WxjS0IRsWrSpU_PXr.m32fEiTOPBzdHLqb6JaTr6hytQVR8L2BNExf9IHaM6y 6MLGiLRftTgKqOVg.xTHC7OP8K6LkjgqEOP7GnoUl_MheeUBJjqEcynaT25m15zMRU_4zMMxkM3G qFi.fsrLOeldIkmGBwFtNAlH4p5G1oS422SzTB_cRnAlRh3sexITBHsBgGCLS1.x5Q7uWKR4Uj8w kc4u29kwrnebj9OrF1SbISKFhD92CLww_jfEI287Hu_dsC_.oOGFqhlcHXzzRu4ntiE2gkY1KRxf L0NhqJOIjWOKtyaiHUfgKMa_HDWm9iFfQaPumNN2itXputD3tHP88vuaoiE0mdSOAUNK.lFqXzY8 IkP_mrSAtSMixhHID.EgtfOu62hd9DpGq7ha9FPW7V6CRIHlWINJP26.h6sOjACL.6IlDqy7oRga 8ytVz6DijJxB69FpssVGN6VvU1x1KNn1ua6dL7J4_ED6uiS6pz0GsY6aDd6sUGZ4yYSB3GU7MiLS XmjNwNX6TTGZzl.6k5kNQJ4sbcjq7iqjtajU_oGofzc142QhhVjQ3KBMQtOXiEJUEYhHMByYDPbm xyLs_ssUd1ra2PZ7BltPq2n6sxt.9sM9JCZmV.TC7moDmA.BfnArVkLLu.NrlWLQxMXSDLuakEsv LM51tq7PMU7DQe2Pa7ho1gm4h6MKpVZjOVbMekWWnYsDtO31Bdi4DfnVNtnhBz2CvIFlvcYvMxMf KjPV.76vuZToY2UVvgSzEdQBWV2HFM72GWIzb6Jz.Uc5QUVy4iCCZzI.FOEYycXi52L.PIr5wGJI IOj6jxeRj21F9YTykVawG.gJuHg5sHAYlhOqm31lYQsvfJHT2RzygxErSxquPZ9gSAJkDAfmcVmi D4JZXp4tZVpFnZA1DVHz.ZzQGaaMePD.kXowLO5uGKUq1rkLCEWYzTXwemUgw4HYk7jfm9B1CdZC avuLdaSOXBpgg1JZM2TV8mWd8Wcsps6Nb0px5UY1Y4XYj9PIbo2FEGfqJBZDJ2NhEf6dWOx2UWC6 2otTc4QrdCMCtMKMMlLRmcr1aApqytQNktwtMVIXLaSL5OLm88r7yfiTH24jskLT9fVwy4UQisYk 7eVGfHrgmomTxISPYLEvsIxBtOO80k7SKGDuLb17uf.ayFiJjflyaRe1OxSo9UgTlunHN1l2SP9E xglTPeT03sohUbcwjO66y8X36X.2m5qIO7xH3bNNjXEXHDVH135lwSIfelSn6RlScqf2YDm4IQF4 - X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic317.consmr.mail.gq1.yahoo.com with HTTP; Fri, 24 Feb 2023 03:31:21 +0000 Received: by hermes--production-gq1-655ddccc9-52j4r (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 70a048c2ce34fa2619fe22cf15f1d3e6; Fri, 24 Feb 2023 03:31:18 +0000 (UTC) Content-Type: text/plain; charset=us-ascii 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 Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.400.51.1.1\)) Subject: Re: FYI: Why META_MODE rebuilds so much for building again after installworld (no source changes) From: Mark Millard In-Reply-To: <93460.1677202939@kaos.jnpr.net> Date: Thu, 23 Feb 2023 19:31:07 -0800 Cc: Bryan Drewery , Current FreeBSD , Peter Content-Transfer-Encoding: quoted-printable Message-Id: References: <3345EBA5-A09C-4E3F-B94D-39F57F56BDBB@yahoo.com> <73088.1611797582@kaos.jnpr.net> <10819.1677108389@kaos.jnpr.net> <76FA98EF-6184-4D7E-A01F-0EE8117D0D10@yahoo.com> <29887.1677115125@kaos.jnpr.net> <27790339-240F-4C97-97C7-38AFD8DE03D5@yahoo.com> <7FB6F619-6E71-4075-8A6C-573564371DD5@yahoo.com> <2655.1677134606@kaos.jnpr.net> <242BB478-B2FE-4BCC-A56E-098F3FEB3EE1@yahoo.com> <42586.1677183334@kaos.jnpr.net> <30.1677189836@kaos.jnpr.net> <1B5FCF8A-0DFD-4246-8464-65A44A40529F@yahoo.com> <93460.1677202939@kaos.jnpr.net> To: "Simon J. Gerraty" X-Mailer: Apple Mail (2.3731.400.51.1.1) X-Rspamd-Queue-Id: 4PNFmW1QxWz4LJp X-Spamd-Bar: ---- 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-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N [I'm back at this again after some time on other subjects.] On Feb 23, 2023, at 17:42, Simon J. Gerraty wrote: > Mark Millard wrote: >=20 >> Simplifying context . . . >> . . . >>> As I mentioned previously, there is no variablity of OBJTOP within = the >>> context of a single make instance - at least not once it starts = running >>> targets. >>>=20 >>>> . . . >>>=20 >>> .MAKE.META.IGNORE_PATHS +=3D ${OBJTOP}/tmp/legacy/usr >>=20 >> I'll use that definition line for the below. >=20 > Ok. >=20 >>> should result in nothing under ${OBJTOP}/tmp/legacy/usr causing a = target >>> to be out of date - just because it is newer. >>=20 >> I'll ignore there that that is skipping too much >> and just show what happens for the 2nd buildkernel >> of 2 in a row when I use that exact line for both >> make runs. >>=20 >> First counts of the "is newer than" lines, counting >> separate program names separately: >>=20 >> # cat = /usr/obj/BUILDs/main-amd64-nodbg-clang/sys-typescripts/typescript-make-amd= 64-nodbg-clang-amd64-host-2023-02-23:16:15:18 | grep "is newer than the = target" | sed - >> e "s@^.*: file '@file '@" | sort | uniq -c | sort -rn | more >> 2553 file = '/usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/tmp/legac= y/usr/sbin/realpath' is newer than the target... >> 1001 file = '/usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/tmp/legac= y/usr/sbin/ln' is newer than the target... >>=20 >=20 > It is of course critical to know what OBJDIR is at this point. > also can you show me the line in the meta file that is matching. So, using specific "is newer than" notice examples instead of the above counts . . . First some output log lines around a few sbin/realpath "is newer than" related Building lines, with the .info lines in place now (I've got both kmod.mk and kern.mk with the .info line, likely producing redundant output but I did not know up front for sure): make[4]: "/usr/main-src/sys/conf/kmod.mk" line 72:=20 .CURDIR=3D/usr/main-src/sys/modules/aac = .OBJDIR=3D/usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/= sys/GENERIC-NODBG/modules/usr/main-src/sys/modules/aac = OBJTOP=3D/usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/s= ys/GENERIC-NODBG/modules/usr/main-src .MAKE.META.IGNORE_PATHS=3D/bin/sh /bin /lib /rescue /sbin /usr/bin = /usr/lib /usr/sbin /usr/share /usr/include /usr/local/etc/libmap.d = /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.am d64/sys/GENERIC-NODBG/modules/usr/main-src/tmp/legacy/usr make[4]: "/usr/main-src/sys/conf/kern.mk" line 3: = .CURDIR=3D/usr/main-src/sys/modules/aac = .OBJDIR=3D/usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/= sys/GENERIC-NODBG/modules/usr/main-src/sys/modules/aac = OBJTOP=3D/usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/s= ys/GENERIC-NODBG/modules/usr/main-src .MAKE.META.IGNORE_PATHS=3D/bin/sh /bin /lib /rescue /sbin /usr/bin = /usr/lib /usr/sbin /usr/share /usr/include /usr/local/etc/libmap.d = /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.am d64/sys/GENERIC-NODBG/modules/usr/main-src/tmp/legacy/usr = /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/sys/GENERI= C-NODBG/modules/usr/main-src/sys/modules/aac/machine.meta: 23: file = '/usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/tmp/legac= y/usr/sbin/realpath' is newer than the target... Building = /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/sys/GENERI= C-NODBG/modules/usr/main-src/sys/modules/aac/machine machine -> /usr/main-src/sys/amd64/include = /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/sys/GENERI= C-NODBG/modules/usr/main-src/sys/modules/aac/x86.meta: 23: file = '/usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/tmp/legac= y/usr/sbin/realpath' is newer than the target... Building = /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/sys/GENERI= C-NODBG/modules/usr/main-src/sys/modules/aac/x86 x86 -> /usr/main-src/sys/x86/include = /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/sys/GENERI= C-NODBG/modules/usr/main-src/sys/modules/aac/i386.meta: 23: file = '/usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/tmp/legac= y/usr/sbin/realpath' is newer than the target... Building = /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/sys/GENERI= C-NODBG/modules/usr/main-src/sys/modules/aac/i386 i386 -> /usr/main-src/sys/i386/include Some lines just following the above are some sbin/ln "is newer than" related Building lines: Skipping meta for beforedepend: .PHONY = /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/sys/GENERI= C-NODBG/modules/usr/main-src/sys/modules/aac/opt_scsi.h.meta: 12: file = '/usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/tmp/legac= y/usr/sbin/ln' is newer than the target... Building = /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/sys/GENERI= C-NODBG/modules/usr/main-src/sys/modules/aac/opt_scsi.h = /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/sys/GENERI= C-NODBG/modules/usr/main-src/sys/modules/aac/opt_cam.h.meta: 12: file = '/usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/tmp/legac= y/usr/sbin/ln' is newer than the target... Building = /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/sys/GENERI= C-NODBG/modules/usr/main-src/sys/modules/aac/opt_cam.h = /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/sys/GENERI= C-NODBG/modules/usr/main-src/sys/modules/aac/opt_aac.h.meta: 12: file = '/usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/tmp/legac= y/usr/sbin/ln' is newer than the target... Building = /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/sys/GENERI= C-NODBG/modules/usr/main-src/sys/modules/aac/opt_aac.h For reference for a sbin/realpath "is newer than" example, the sys/modules/aac/machine.meta : # Meta data file = /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/sys/GENERI= C-NODBG/modules/usr/main-src/sys/modules/aac/machine.meta CMD @case machine in machine) path=3D/usr/main-src/sys/amd64/include = ;; *) path=3D/usr/main-src/sys/machine/include ;; esac ; = path=3D`realpath $path`; echo machine "->" $path ; ln -fns $path = machine CWD = /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/sys/GENERI= C-NODBG/modules/usr/main-src/sys/modules/aac TARGET machine -- command output -- machine -> /usr/main-src/sys/amd64/include -- filemon acquired metadata -- # filemon version 5 # Target pid 84728 # Start 1677207916.433304 V 5 E 84729 /bin/sh R 84729 /etc/libmap.conf R 84729 /usr/local/etc/libmap.d R 84729 /usr/local/etc/libmap.d/mesa.conf R 84729 /var/run/ld-elf.so.hints R 84729 /lib/libedit.so.8 R 84729 /lib/libc.so.7 R 84729 /lib/libtinfow.so.9 R 84729 /usr/share/locale/C.UTF-8/LC_CTYPE F 84729 84730 E 84730 = /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/tmp/legacy= /usr/sbin/realpath R 84730 /etc/libmap.conf R 84730 /usr/local/etc/libmap.d R 84730 /usr/local/etc/libmap.d/mesa.conf R 84730 /var/run/ld-elf.so.hints R 84730 /lib/libc.so.7 X 84730 0 0 E 84729 = /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/tmp/legacy= /usr/sbin/ln R 84729 /etc/libmap.conf R 84729 /usr/local/etc/libmap.d R 84729 /usr/local/etc/libmap.d/mesa.conf R 84729 /var/run/ld-elf.so.hints R 84729 /lib/libc.so.7 D 84729 machine L 84729 '/usr/main-src/sys/amd64/include' 'machine' X 84729 0 0 # Stop 1677207916.435305 # Bye bye For reference for a sbin/ln "is newer than" example, the sys/modules/aac/opt_scsi.h.meta : # Meta data file = /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/sys/GENERI= C-NODBG/modules/usr/main-src/sys/modules/aac/opt_scsi.h.meta CMD ln -sf = /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/sys/GENERI= C-NODBG/opt_scsi.h opt_scsi.h CWD = /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/sys/GENERI= C-NODBG/modules/usr/main-src/sys/modules/aac TARGET opt_scsi.h -- command output -- -- filemon acquired metadata -- # filemon version 5 # Target pid 84728 # Start 1677207916.439304 V 5 E 84735 = /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/tmp/legacy= /usr/sbin/ln R 84735 /etc/libmap.conf R 84735 /usr/local/etc/libmap.d R 84735 /usr/local/etc/libmap.d/mesa.conf R 84735 /var/run/ld-elf.so.hints R 84735 /lib/libc.so.7 D 84735 opt_scsi.h L 84735 = '/usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/sys/GENER= IC-NODBG/opt_scsi.h' 'opt_scsi.h' X 84735 0 0 # Stop 1677207916.440304 # Bye bye > If you add the .info line I suggested in kern.mk or kmod.mk > you should get some useful info. Added to both for now. The material above has the output from them from just before a "is newer than" notice. >> Thousands of rebuilt things based on: >>=20 >> . . ./tmp/legacy/usr/sbin/realpath >> . . ./tmp/legacy/usr/sbin/ln >>=20 >> It appears that buildkernel does not use an OBJTOP definition >> that references: >=20 > It is possible it does not have a "normal" value for it. > Kernel builds start in the objdir so .CURDIR is actually under > OBJTOP, so unless the makefiles have appropriate logic for that case, > and depending on how OBJTOP is derrived, you may have a bogus value. >=20 > The fix in that case would be the makefile setting OBJTOP. >=20 >>=20 >> /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64 >>=20 >> in my context. >>=20 >> For reference of Build lines paired with a few of those "is newer >> than" lines: >>=20 >>=20 >> I've still no clue of a notation that avoids this for >> my choice to use personal MAKEOBJDIRPREFIX paths: >=20 > That should work, looking at share/mk/src.sys.obj.mk > though looks like you might get >=20 > OBJROOT?=3D ${_default_makeobjdirprefix}${SRCTOP}/ >=20 > which may not be valid for a kernel build. > At least ${.OBJDIR} will not have that ${OBJROOT} as a prefix > and some of the settings for OBJTOP look just wrong to me: >=20 > OBJTOP:=3D ${OBJROOT:H} >=20 > is the opposite of what the relationship b/w OBJROOT and OBJTOP are in > DIRDEPS_BUILD but it looks like >=20 > OBJTOP:=3D ${OBJROOT}${MACHINE}.${MACHINE_ARCH} >=20 > is more likely to be used, but given the above default for OBJROOT > that is unlikely to work for a kernel build. >=20 > Looks like share/mk/src.sys.obj.mk grok's SB (the setup I/we use) so = you > can take control by setting SB and SB_OBJROOT to anything you like and > it should be used for OBJROOT and presumably hence OBJTOP even for a > kernel build. Though I normally use MAKEOBJDIR (similar to the way it > is set in _default_makeobjdir), I don't know how well that works with > legacy targets though - there's a lot of baked in assumptions about > using MAKEOBJDIRPREFIX. >=20 > Again that .info line I gave you would provide some useful clues. >=20 =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Fri Feb 24 03:54:40 2023 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 4PNGK65NV2z3t9wD for ; Fri, 24 Feb 2023 03:56:10 +0000 (UTC) (envelope-from sjg@juniper.net) Received: from mx0b-00273201.pphosted.com (mx0b-00273201.pphosted.com [67.231.152.164]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.pphosted.com", Issuer "Thawte RSA CA 2018" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4PNGK63fdCz4NYJ; Fri, 24 Feb 2023 03:56:10 +0000 (UTC) (envelope-from sjg@juniper.net) Authentication-Results: mx1.freebsd.org; none Received: from pps.filterd (m0108160.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 31O1Q3Cb004837; Thu, 23 Feb 2023 19:55:49 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=to : cc : subject : in-reply-to : references : from : mime-version : content-type : content-id : content-transfer-encoding : date : message-id; s=PPS1017; bh=eWdkrG9jza1d+nNs0sPkHE9hRb3HSdgTq5bf5KHTUoc=; b=mbFMFjltl6j3TX1UdL3qUI7dz8iEKmYGblJaGTtaw+12hcqPb0eDAoAEX3sxFkGgpsKR VWi/i0rnvISXBUkjrkbxVt7jaqdt966GwPnBeKc8UHRk6jmXbKHrzLtv7il1raBj3mAq taokEATM/u3cL8NeuV4HQ5m6AYaa9gUyujzbxpVBqPynw3l/UIw2Kt3lMp+C2gmEtZJ0 UuUWgPf8dmw30m3BhxagGR00BZ6pzsvNfBw0QI5MRi3DNtpNw7iJRovap/8Kpn50zZGo Z/acAldLIRn633aDFo1pMbcQKm6ee4XY4xJYwyxA5dBbSumBADJ+IZngrVw7LnAebc+q 9Q== Received: from mw2pr02cu002-vft-obe.outbound.protection.outlook.com (mail-westus2azlp17013037.outbound.protection.outlook.com [40.93.10.37]) by mx0b-00273201.pphosted.com (PPS) with ESMTPS id 3nxkjkg72x-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 23 Feb 2023 19:55:48 -0800 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=WOZBi1K/D6ZMpPWgWWaQWMNmHwS47RBUkBgpmgOA9aNDTUF5z7kjUWbI3kKXmjaa4LI/3Amt6kUlkcnMDwUnM8cRRTrh5vH13T2P0UYKn0gIA1svPVZbM0IaOSfxzZCYK7bHbUo+RZ8oqk9CptYVWKXbyaXaXroVVe9bvurludrt2vYJvlziLcUIsMHnIo9ti4qFIpkpHm4E5y4wjQbjEEw8MdJkRD3fSrIDplbj8S6CGeSrU4vjs+kXTmx1/QtSg+cwJvV0bUhF8omn2+YY4yRCgDvofIBBFqHpvJPTdx1B5NhDjI0LD9gnSV+bz2P3tfucbNVSrJLorIyeIHJhgw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=eWdkrG9jza1d+nNs0sPkHE9hRb3HSdgTq5bf5KHTUoc=; b=F6G5GJ1KBAqlmOxLO49zPpJuG+9CXKojFBOiDcMyJyulzAjQKQnTT7cLHTxgQkRCRNn2PwJ9Bc0isX/Sd3m/IJdWAAvl166um2w6HgS31PF1T88C9k3MR5xDOwItyllW6IKjKycMaxgXTPs02Q2VEIDWQQTgPT23C/Dv29sp0fO0YUrdJKDcxCU8fv+meAIvlKlYEiUSKonqU0XEJP650lKHHhp2XSogpThbphq2claiZvC9rtPBxp3NBxvUBnT72W64rfV4wzWSjvjshK+wPOWheybqsdK+sW11VvPlaq7Pw/iAGYFcfbF7VUc+3JqoXCwki3KI5R05VGmMMR/3DA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=softfail (sender ip is 66.129.239.14) smtp.rcpttodomain=yahoo.com smtp.mailfrom=juniper.net; dmarc=fail (p=reject sp=reject pct=100) action=oreject header.from=juniper.net; dkim=none (message not signed); arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=eWdkrG9jza1d+nNs0sPkHE9hRb3HSdgTq5bf5KHTUoc=; b=dzog0ts9+R6ll++wSfk2C2yCWG71mkb7PTP+MvjffdYl/jfANYXJd3R1SIIJE0aG1wkPtY3Ri1OZuAJ/mOeG6/CNqOGxeYDU/r7u4W+KwKHeOcZoB2DcbdRUhO5L99Pm4JfB1wFysGKdWA6W0rw7EW0iZTn57Qx3ttQZaA6cfpY= Received: from BN0PR02CA0052.namprd02.prod.outlook.com (2603:10b6:408:e5::27) by MWHPR0501MB3819.namprd05.prod.outlook.com (2603:10b6:301:7a::39) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6134.19; Fri, 24 Feb 2023 03:55:41 +0000 Received: from BN8NAM12FT019.eop-nam12.prod.protection.outlook.com (2603:10b6:408:e5:cafe::8b) by BN0PR02CA0052.outlook.office365.com (2603:10b6:408:e5::27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6134.21 via Frontend Transport; Fri, 24 Feb 2023 03:55:41 +0000 X-MS-Exchange-Authentication-Results: spf=softfail (sender IP is 66.129.239.14) smtp.mailfrom=juniper.net; dkim=none (message not signed) header.d=none;dmarc=fail action=oreject header.from=juniper.net; Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.14 as permitted sender) Received: from p-exchfe-eqx-01.jnpr.net (66.129.239.14) by BN8NAM12FT019.mail.protection.outlook.com (10.13.183.160) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6156.11 via Frontend Transport; Fri, 24 Feb 2023 03:55:40 +0000 Received: from p-exchbe-eqx-01.jnpr.net (10.104.9.14) by p-exchfe-eqx-01.jnpr.net (10.104.9.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.30; Thu, 23 Feb 2023 21:55:40 -0600 Received: from p-exchbe-eqx-01.jnpr.net (10.104.9.14) by p-exchbe-eqx-01.jnpr.net (10.104.9.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.30; Thu, 23 Feb 2023 21:55:40 -0600 Received: from p-mailhub01.juniper.net (10.104.20.6) by p-exchbe-eqx-01.jnpr.net (10.104.9.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.30 via Frontend Transport; Thu, 23 Feb 2023 21:55:40 -0600 Received: from kaos.jnpr.net (kaos.jnpr.net [172.23.255.201]) by p-mailhub01.juniper.net (8.14.4/8.11.3) with ESMTP id 31O3tdAp001909; Thu, 23 Feb 2023 19:55:39 -0800 (envelope-from sjg@juniper.net) Received: by kaos.jnpr.net (Postfix, from userid 1377) id 2B16D210E9; Thu, 23 Feb 2023 19:54:40 -0800 (PST) Received: from kaos.jnpr.net (localhost [127.0.0.1]) by kaos.jnpr.net (Postfix) with ESMTP id 27C5C20F7F; Thu, 23 Feb 2023 19:54:40 -0800 (PST) To: Mark Millard CC: Bryan Drewery , Current FreeBSD , Peter , Subject: Re: FYI: Why META_MODE rebuilds so much for building again after installworld (no source changes) In-Reply-To: References: <3345EBA5-A09C-4E3F-B94D-39F57F56BDBB@yahoo.com> <73088.1611797582@kaos.jnpr.net> <10819.1677108389@kaos.jnpr.net> <76FA98EF-6184-4D7E-A01F-0EE8117D0D10@yahoo.com> <29887.1677115125@kaos.jnpr.net> <27790339-240F-4C97-97C7-38AFD8DE03D5@yahoo.com> <7FB6F619-6E71-4075-8A6C-573564371DD5@yahoo.com> <2655.1677134606@kaos.jnpr.net> <242BB478-B2FE-4BCC-A56E-098F3FEB3EE1@yahoo.com> <42586.1677183334@kaos.jnpr.net> <30.1677189836@kaos.jnpr.net> <1B5FCF8A-0DFD-4246-8464-65A44A40529F@yahoo.com> <93460.1677202939@kaos.jnpr.net> Comments: In-reply-to: Mark Millard message dated "Thu, 23 Feb 2023 19:31:07 -0800." From: "Simon J. Gerraty" X-Mailer: MH-E 8.6+git; nmh 1.7.1; GNU Emacs 28.1 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 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <13467.1677210880.1@kaos.jnpr.net> Content-Transfer-Encoding: quoted-printable Date: Thu, 23 Feb 2023 19:54:40 -0800 Message-ID: <17672.1677210880@kaos.jnpr.net> X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BN8NAM12FT019:EE_|MWHPR0501MB3819:EE_ X-MS-Office365-Filtering-Correlation-Id: 7e091a75-6b21-4f0d-a486-08db161aff43 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: Vg0EBfGh/ORnmFgaU2AnY2hpZiMS9DMr+yyvuuX86t1o+MGVSDFgpvGs+byWdF4u/E5Jt0gkLCrT8V9t5OjQcMfWg/LxxJCJl1QqyoPQBaTpKUbfUQVfigJ0MhgqHDmUgkqqN7rUkGw/xciajMXkEAYOVetvClxIDR7b0Tn87WF07a7T5sVRn+QlbyfXAypBe7vzBmrpn4lXfE5VY51OauKZGE8ZGHGdZM3p1FDJ6g0b+3XGkKN2xzDhs26/tUIB6pdNtO1WMPiSOYpzyI9sgnWV9+EGufhTjLTc4zJ4j83N+y7Rtz6LMCUrUfuzpibML6Skm7r9aVCXQJI0cVB5JjcFZ1q1RoM5l4CzAmNt3xlHFEFROF2FQ4wQv++Hp8CySWYhRbK25qgP6WYDS8nFju+2jkqYWcZmn7qg3JzIj62XgkM4HTSK9VdI8vnqJ2WzYWQC7IJX2hk/HTe1stvghnSsWBZvjGJDd12cR0WqlhuZweygKvk0PBg8lONkWkFWHXbUGfMIrd5ESw7tfqJZIz5datztYdzAnhn4C88Q2pyTRHvaTUrI+8wUBsBuLS4zd3fLSKX5kCPYRyfFx11pJPlpYeStdyWHob2irmRKH46sl0I+L+u2IVI+AZREMMudrd+aklgXQkXqr7cBD7J/I8A2sOsbjO+9L4lYc2tN3E/uFLSCoAC2j/Lst2ea5gyzVU+DNpLkyXoBESp/rHELvOSpn8HfN8szHvw0ZQ3A8BWGB+ByLjN0UU7dRE5GRAp4riwWFQh5iNl/g2Uc6vI0Ehu2wvThpC4dREmiiMAlGps= X-Forefront-Antispam-Report: CIP:66.129.239.14;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:p-exchfe-eqx-01.jnpr.net;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230025)(4636009)(396003)(136003)(376002)(39860400002)(346002)(451199018)(46966006)(36840700001)(40470700004)(186003)(107886003)(26005)(6266002)(70586007)(7126003)(9686003)(336012)(7696005)(478600001)(316002)(54906003)(47076005)(70206006)(36860700001)(4326008)(41300700001)(2906002)(8676002)(6916009)(81166007)(5660300002)(82740400003)(8936002)(356005)(40460700003)(40480700001)(55016003)(82310400005)(86362001)(36900700001);DIR:OUT;SFP:1102; X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 24 Feb 2023 03:55:40.9391 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 7e091a75-6b21-4f0d-a486-08db161aff43 X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4;Ip=[66.129.239.14];Helo=[p-exchfe-eqx-01.jnpr.net] X-MS-Exchange-CrossTenant-AuthSource: BN8NAM12FT019.eop-nam12.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR0501MB3819 X-Proofpoint-GUID: nR_tpNrgoASK_UqDI75ECaBD65-Mf6rg X-Proofpoint-ORIG-GUID: nR_tpNrgoASK_UqDI75ECaBD65-Mf6rg X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.219,Aquarius:18.0.930,Hydra:6.0.562,FMLib:17.11.170.22 definitions=2023-02-23_15,2023-02-23_01,2023-02-09_01 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 mlxlogscore=818 phishscore=0 impostorscore=0 lowpriorityscore=0 mlxscore=0 priorityscore=1501 bulkscore=0 suspectscore=0 spamscore=0 malwarescore=0 clxscore=1015 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2212070000 definitions=main-2302240029 X-Rspamd-Queue-Id: 4PNGK63fdCz4NYJ X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:22843, ipnet:67.231.152.0/24, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N > = > First some output log lines around a few sbin/realpath "is newer than" > related Building lines, with the .info lines in place now (I've > got both kmod.mk and kern.mk with the .info line, likely producing > redundant output but I did not know up front for sure): > = > make[4]: "/usr/main-src/sys/conf/kmod.mk" line 72: > .CURDIR=3D/usr/main-src/sys/modules/aac > .OBJDIR=3D/usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd6= 4/sys/GENERIC-NODBG/modules/usr/main-src/sys/modules/aac > OBJTOP=3D/usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64= /sys/GENERIC-NODBG/modules/usr/main-src So as you can see that OBJTOP not does provide a match for where /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/tmp/legacy= /usr/sbin/realpath is you really want it fixed at /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64 which is difficult given the way it is defined in src.sys.obj.mk Perhaps you want to be using .MAKE.META.IGNORE_PATHS+=3D ${MAKEOBJDIRPREFIX}/tmp/legacy/usr or is that ${MAKEOBJDIRPREFIX}/${TARGET}.${TARGET_ARCH}/tmp/legacy/usr = From nobody Fri Feb 24 04:57:20 2023 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 4PNHh13c1kz3tFQW for ; Fri, 24 Feb 2023 04:57:37 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic304-23.consmr.mail.gq1.yahoo.com (sonic304-23.consmr.mail.gq1.yahoo.com [98.137.68.204]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4PNHh10zSxz4TVr for ; Fri, 24 Feb 2023 04:57:36 +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=1677214654; bh=B8fyhldx+dTL9bkWv9G6yFukQ3Bxz0Fs2vn9s6Jfycw=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=YX2hZF2ONMmpZQarX3/t81TJ4uI8PVe+NfxIoYE9Wd5n62uyiSJB5dcbGRRLrI3qtaRzQ79n1Wg0EG93NS3CQFVKRWg4zufaUjEEhlHSvWOq0TFffLQi+jVtgk/EiBG9NIbPhjt4qNfJiYGQ0ULfTLQdrigcR6oUE1vGB4JAY4wWVmkkyMQIqg7GohrvRWPC5poaJ9D+EkEHZm9xGPIrR7INuCi1elfaGoYxvbL64z6ov8PkklmTDX3dOKTN5TsEslXkZh2v5sYt4eZRRnM70m7J0PpRpoyUqNQa4vMxSJF14xBW+R+PFKolJJUvBTjZYH6LU5t+Bnms2bDMqVp7Og== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1677214654; bh=doYlk6SU4ihlz+oHMLA7rl5D2gsHShOw+fqU/Hk/hZ0=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=bA8ApsNZRfu1RslGyjS1k4N8vUqXKDcn2AxzrSTqTpedW2ncpB2+bA12eD/WLqTaLOl5pbp4Qlhs+WbhbnWgQLO/ZZZhLoAKcl5EgSsU6JVy9PuP2Iupf5L3NZnQOvveqHROgqR9ZJCjjk08u6cdiktkt+4FhaJCE2vFdYr991NGzNzMqnWX1ISGlb4630N5dZO0dtWhln+KYL3o6y78vbPR8KAF5b737uvDQEecTRU5MKIatViOHzHz+/sIXswCn8320oNdv62uFYFXjv1sMZXJoevo/49XXDFuM1iT9xOCRfGACBgUM1i5/20bV9Zp3kKc3Ipvji9xkpOVn7orcg== X-YMail-OSG: X1lGQ3QVM1nV63VF.ruNM2tAZeQVrcpScUvsCqG9n3wOQnJK01QE5JxPng3Oil9 vP2KhZoQKsLsZQjnaprZIF.InT0arg8ExkW4NOmIgXMozn0aBQgiEi8wfY_PzEqsWEWBoUfWHTJB 1cddHb_qXz9m6bSNDaHsnu83VvD5wUhkZfTU4vqNg80zRXIt0TYoIklUa_atlnFFGCg6KWe7Te3y UjGxHcM8ohhMuEPLg17ZjE1aFmi111Ovg49Zx.FFMgMOlwWmEpjuC4nm73g_TSp_6ea_Vj0dzOmt e_hi9Rkbyaki_XZyiXlVhPV1mDF6JcxQ0C2s8BuDHPmbpP7HPSBY3Lk67R3syf7.8dOCSSw5XHhY mVBw5wEkO9z7OZq41LRCaFo2Zb_0yOwxyi8UaRMC6SGOOpyh3wW9rlR4jEKBHDkV7n.aQgb7nZlR kSYjO0o3yL1wQNXW9PH6ctq0nsBbHJgywOTnsgVAr0ho2DqGhpiG.HCrV_K8MI2_Dfb69mCwOPMw AZpQn2oPsxSWhyLzRluebVdPxQzxDzENxYJbdhO5sKkbUYMnc6A13nKmb5W8Jv63272S0HCIuC3a 29ch9aahOBS4SYD0dAIZpy4DoMyoV0weYdEDxH1otRiOaY3dOwP5s.ExBj4fVLD3Dd7kLW1zSLsq byh9w0.O8B116HDFpyuzYaYE5UescqdaL6wQWVrThY5Ec7H2of0iH8aemIqNHemE9JXyt4vSSYlc d28PokrnrehuEve1bnQj0AKlBalSN_rjQ_CQdJNuSz7z.l.f4v1uH6HHO2c7UBjoAaGKCNd_BRr6 glr_QwsPTbEkj0M.yHRNoHVsziRlKOC3PynnpwKNRa0ew5alyuxpIlZ2f.smVcGSY2YkMDRW17wQ T7ZdAXvZz3JoEjJfs.S7Smg2aAYXJFhK0anENSrvjBYbyZZpJSnkx7OIHRdQm2teFrKsbc40.xyu Y7WyHXvQDLndjh74gDi6.4mrPLN.bH8ZgTSvUhj2FRcb.we5Qhib4_CHVEuZKqhn6zxMiTenB5pz uW5Ia6npSdUD.zvE_3DHv0j4qLkaZRH64xwtmAd2iK1peMRUJlJ8eLajJUcaIy_6b1yVUw02U0PG k8O8OyJ5Po_WXnOQMc2_SgRW20azRk_.0mf1jun3eOvbp2HWBmXz1UVbdDcMplYabdUT.9sKumY5 XtcirovJTnxGY2CsorhG5Pv1yyVtYhtEz2lcuJKkz0wKzuta9QMDAVClvTwo2dI6aPcuxkO4Mxfx itH4cl3zH64Fl1HNFOL4F6yjyDmyVr1CDPUKzkXm2FSk9DqZWt3pmTPQwi1Hzu5yo_JWySz99wfx 3O6hjcmjG9nkB5t6IWoT.hsKu8WgOzuS6sh7byVtw4oJoSASGhabZmXCYb9NwIy7tCx6vVxvc4EP 8xAORv7KRytmS1_._WNmo7AWzEgBRjE10160xFDm2xZq9ZxFwba_G.IIKWCqXxaF.bt7iF6bIOi2 Uhjcw4v2dsJc_W314hUNSZPRGSG5.VfpyCGde2551RRYLo3anZ9HhKWogAOcdRcRWwBsCg3me.zG b1ncdnSWyJEn7ByC56mFwM76QSo2V6Nyi6mh58bGOcgA08SnDZt55a_o.Rg9W0UCtzhL35OtqtEH 1IefK8hgyc8k.DZW0Aty2hWUoUGW97wfMtBfVYa2Y5D0UyhSDyqeXT9v3UnN.JcO.Jt.mS9F.9Yn jTuw68DXFNaXQCDI1M3jSfRW5pNzwcYMyPVmG_V5DYBWarxW4ggEP4cJ5jEsqB7Im9orNZFQDCKJ cvAiqu2EiCNm0drie5JiWnQKhpjBefwB4mOI.S9jEUX5xcsFMkW4E.l3t9kudoMYtAOs9uVWqGMo W0wsEe6iRJMXyaJdr3ET0lgYwVBCDkw2DDd3NLRDaRrowmxE_otGDSJfKJgJssm34ZJnBW2OzVjs PVFXouAPvMoPOueIxLdTzYDfyfZwiYHfYofNULIUXA.YIcvHYUSCOmwafiWq0fk5UtP4yS0sxWUh JhZkcfj964h0_a0_mkAaypQyN_Lt1fFhZa_yKJjY8IQ42YyNhAZNRTR5w4dXRMC2dIpN8jLYhTGa 41JgiUD6u2Cdou.YSj00eiixCWLpR6TD0kOJMcbPny_2_FfYtKwlNw5byc9mHp78HPRAWO9S0TJ9 5VySvKzlNPMD2ZNJYIBEYuDYtJyvS7Itmeet9ydM5bsZwuPIGSAs9eaxIN_.i6ty1DV4mmFnab3y u8g2cQwImedKvfkGxrI6aiDRepzCf9tB8L6_kqmDcuWjDDaTq1k1fXfm0Erei0VRP3AybSHs5 X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic304.consmr.mail.gq1.yahoo.com with HTTP; Fri, 24 Feb 2023 04:57:34 +0000 Received: by hermes--production-gq1-655ddccc9-6nnrh (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 7612117519ce38da470f16f4877f2d61; Fri, 24 Feb 2023 04:57:31 +0000 (UTC) Content-Type: text/plain; charset=us-ascii 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 Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.400.51.1.1\)) Subject: Re: FYI: Why META_MODE rebuilds so much for building again after installworld (no source changes) From: Mark Millard In-Reply-To: <17672.1677210880@kaos.jnpr.net> Date: Thu, 23 Feb 2023 20:57:20 -0800 Cc: Bryan Drewery , Current FreeBSD , Peter Content-Transfer-Encoding: quoted-printable Message-Id: <21F1E7D4-D709-4DFF-98D6-51795B9BB291@yahoo.com> References: <3345EBA5-A09C-4E3F-B94D-39F57F56BDBB@yahoo.com> <73088.1611797582@kaos.jnpr.net> <10819.1677108389@kaos.jnpr.net> <76FA98EF-6184-4D7E-A01F-0EE8117D0D10@yahoo.com> <29887.1677115125@kaos.jnpr.net> <27790339-240F-4C97-97C7-38AFD8DE03D5@yahoo.com> <7FB6F619-6E71-4075-8A6C-573564371DD5@yahoo.com> <2655.1677134606@kaos.jnpr.net> <242BB478-B2FE-4BCC-A56E-098F3FEB3EE1@yahoo.com> <42586.1677183334@kaos.jnpr.net> <30.1677189836@kaos.jnpr.net> <1B5FCF8A-0DFD-4246-8464-65A44A40529F@yahoo.com> <93460.1677202939@kaos.jnpr.net> <17672.1677210880@kaos.jnpr.net> To: "Simon J. Gerraty" X-Mailer: Apple Mail (2.3731.400.51.1.1) X-Rspamd-Queue-Id: 4PNHh10zSxz4TVr X-Spamd-Bar: ---- 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-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N On Feb 23, 2023, at 19:54, Simon J. Gerraty wrote: >=20 >>=20 >> First some output log lines around a few sbin/realpath "is newer = than" >> related Building lines, with the .info lines in place now (I've >> got both kmod.mk and kern.mk with the .info line, likely producing >> redundant output but I did not know up front for sure): >>=20 >> make[4]: "/usr/main-src/sys/conf/kmod.mk" line 72: >> .CURDIR=3D/usr/main-src/sys/modules/aac >> = .OBJDIR=3D/usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/= sys/GENERIC-NODBG/modules/usr/main-src/sys/modules/aac >> = OBJTOP=3D/usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/s= ys/GENERIC-NODBG/modules/usr/main-src >=20 > So as you can see that OBJTOP not does provide a match for where > = /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/tmp/legacy= /usr/sbin/realpath is >=20 > you really want it fixed at >=20 > /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64 >=20 > which is difficult given the way it is defined in > src.sys.obj.mk Yep, but possibly understated. > Perhaps you want to be using >=20 > .MAKE.META.IGNORE_PATHS+=3D ${MAKEOBJDIRPREFIX}/tmp/legacy/usr > or is that ${MAKEOBJDIRPREFIX}/${TARGET}.${TARGET_ARCH}/tmp/legacy/usr=20= >=20 I had started with trying to use MAKEOBJDIRPREFIX but it appeared to end up with an empty expansion in something I'd looked at, making the addition to .MAKE.META.IGNORE_PATHS ineffective. But with the .info lines in place, I should probably recheck an example with ${MAKEOBJDIRPREFIX} in it. (Expecting .MAKE.META.IGNORE_PATHS to not work but showing what happens for the MAKEOBJDIRPREFIX use.) This turns out to be different for "modules" vs. "pure kernel". I start with a "modules" example below. So for .MAKE.META.IGNORE_PATHS +=3D ${MAKEOBJDIRPREFIX}/tmp/legacy/usr . . . make[4]: "/usr/main-src/sys/conf/kmod.mk" line 72:=20 .CURDIR=3D/usr/main-src/sys/modules/aac = .OBJDIR=3D/usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/= sys/GENERIC-NODBG/modules/usr/main-src/sys/modules/aac = OBJTOP=3D/usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/s= ys/GENERIC-NODBG/modules/usr/main-src .MAKE.META.IGNORE_PATHS=3D/bin/sh /bin /lib /rescue /sbin /usr/bin = /usr/lib /usr/sbin /usr/share /usr/include /usr/local/etc/libmap.d = /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/sys/GENERI= C-NODBG/modules/tmp/legacy/usr make[4]: "/usr/main-src/sys/conf/kern.mk" line 3: = .CURDIR=3D/usr/main-src/sys/modules/aac = .OBJDIR=3D/usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/= sys/GENERIC-NODBG/modules/usr/main-src/sys/modules/aac = OBJTOP=3D/usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/s= ys/GENERIC-NODBG/modules/usr/main-src .MAKE.META.IGNORE_PATHS=3D/bin/sh /bin /lib /rescue /sbin /usr/bin = /usr/lib /usr/sbin /usr/share /usr/include /usr/local/etc/libmap.d = /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/sys/GENERI= C-NODBG/modules/tmp/legacy/usr = /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/sys/GENERI= C-NODBG/modules/usr/main-src/sys/modules/aac/machine.meta: 23: file = '/usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/tmp/legac= y/usr/sbin/realpath' is newer than the target... Building = /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/sys/GENERI= C-NODBG/modules/usr/main-src/sys/modules/aac/machine So, it looks like it ended up with MAKEOBJDIRPREFIX being: = /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/sys/GENERI= C-NODBG/modules But looking outside the "modules" part of the kernel build log ends up showing: .MAKE.META.IGNORE_PATHS=3D/bin/sh /bin /lib /rescue /sbin /usr/bin = /usr/lib /usr/sbin /usr/share /usr/include /usr/local/etc/libmap.d = /tmp/legacy/usr So MAKEOBJDIRPREFIX expanded to empty, resulting in: /tmp/legacy/usr . So: more can-not-get-there-from-here. I've still no clue of a notation that will work. (It would need to apply to buildworld as well, making for more constraints than just working for buildkernel.) As for: ${MAKEOBJDIRPREFIX}/${TARGET}.${TARGET_ARCH}/tmp/legacy/usr my memory is that ${TARGET}.${TARGET_ARCH} are supposed to only be use in the top level makefiles. But, just seeing what results . . . = /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/sys/GENERI= C-NODBG/modules/amd64.amd64/tmp/legacy/usr Still not right for "modules". I'll note that outside modules, it is: /amd64.amd64/tmp/legacy/usr and still not right (MAKEOBJDIRPREFIX expanded to empty). I still do not know notation to make .MAKE.META.IGNORE_PATHS effective for the specific list of tmp/legacy/usr/sbin/* examples in question. Effectively, it appears that the coverage of .MAKE.META.IGNORE_PATHS is just incomplete (via the notational constraints it is used within). =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Fri Feb 24 07:33:54 2023 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 4PNMB03pB4z3tdn3 for ; Fri, 24 Feb 2023 07:35:20 +0000 (UTC) (envelope-from sjg@juniper.net) Received: from mx0b-00273201.pphosted.com (mx0b-00273201.pphosted.com [67.231.152.164]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.pphosted.com", Issuer "Thawte RSA CA 2018" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4PNMB01pLLz3F48; Fri, 24 Feb 2023 07:35:20 +0000 (UTC) (envelope-from sjg@juniper.net) Authentication-Results: mx1.freebsd.org; none Received: from pps.filterd (m0108162.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 31O0P74P022589; Thu, 23 Feb 2023 23:34:58 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=to : cc : subject : in-reply-to : references : from : mime-version : content-type : content-id : date : message-id; s=PPS1017; bh=HsJtb39bkQ3FTIncbUld9FkQW5aawHsch90I4g9l4oA=; b=o08/cfkOY//NWR+BN6/MPp431l606M6DlZq9F2zJpLIoagpiFS9/MfuQoruutxhVnz8y f5UxYdsTqHFIL9iaDFlTX6LFnlbbtnHei7YnJen2xWTA83NJBjTZqO50VMG/SFsp5zVe Jb/XOd3CeSeuviiEInjlO7xkQ0L3Rlnt98N0V1m912ekLV/6yABGfayhKO94KYCEuWmP olL3ClYg0jcsxINCnYi3TuCgki33Rgo/zk/rGT+cbYLFLWuQOoNWG9c6FI2aYMFCb7kp NRc3A9y7aKakbjbygtdZDUzxbFvBMtKB6bnQnFjWd5sYyZd2kIH5Tp1yYX0YqYwJ/fTt Tw== Received: from cy4pr02cu007-vft-obe.outbound.protection.outlook.com (mail-westcentralusazlp17011010.outbound.protection.outlook.com [40.93.6.10]) by mx0b-00273201.pphosted.com (PPS) with ESMTPS id 3nxjp1rnww-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 23 Feb 2023 23:34:58 -0800 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=iBXT4NRTxJO/myiayCrsOmPoT4ZKbrLI+G7yCGEfn6usS8/QA0AGEgsBGZb+juIuZAgrBjDD/YAEU3tyaRK6bRoVfm+mIzNR/zNPpfXskMdvBN1boE2OOZ1ORyzw8r1UGxu3OWgehFxk1VR3j7sQOkWrttfiLLoEhXtjDy39W1D1Qx/ugX4OA19fJRnNxrHAZnWCUdGFfBKKAyEDLzJgQXZZVkVFh93lDmejVRmNLYtl6lOJSJxxn8MtC3cIGAt25vpKvx0CU5FCHnKLQ2MHAownqv9jlDoKuu+1yX1b+CHJ8YmojjNeWn9LZ2B03mcy0QAq/IfqUm0XT0uzDcMa9g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=HsJtb39bkQ3FTIncbUld9FkQW5aawHsch90I4g9l4oA=; b=WOZYV7GFMdFpWmagxCpc7L7cj9CsDmdBZFdQu2Ahj/+a5hepCwEWgcrx7Tp8dZqsQlcbZZGP7gx6U9w8zjbrNuIUrR7FX5DZctEGoy7H88Hey0i1g4yxVKX6rypteoB6+r7dYfsdTnXDIq8kgwPHGfxHvE7ZNpVkiytcg/z9UTe6ERVRb2SP+GjJrnGnvGtUo2noX/r33bwwE/agDb4KjKIAOcy+vAAuwArNkmv+5fYtG3yqT5Zi8GYysZPzTqcXEWXFZ1zVQnZMOhB562Ht1cQ83BbQDMzJgApTNszg3JJD7pS+k89988IRQ9oMPiKCiIZ5DsgimtF5Kjx6D1r3TA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=softfail (sender ip is 66.129.239.15) smtp.rcpttodomain=yahoo.com smtp.mailfrom=juniper.net; dmarc=fail (p=reject sp=reject pct=100) action=oreject header.from=juniper.net; dkim=none (message not signed); arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=HsJtb39bkQ3FTIncbUld9FkQW5aawHsch90I4g9l4oA=; b=U3d3QJlgiBAqcPIEI6OHuypOL6frgx628Ftr1y5b6+C+oEL+pWXPfpIn0moDCxC4dBrxqGK21XO8JWCUs29FWHECdupjZZ0rWSR6l7SqsUsO2szrtKdR1eoOzJAvvORl14LDaMdT2hnBZVapMBot+kwyPauaCYFh0WmBUZumu+4= Received: from DM6PR07CA0044.namprd07.prod.outlook.com (2603:10b6:5:74::21) by BLAPR05MB7490.namprd05.prod.outlook.com (2603:10b6:208:296::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6134.24; Fri, 24 Feb 2023 07:34:55 +0000 Received: from DM6NAM12FT095.eop-nam12.prod.protection.outlook.com (2603:10b6:5:74:cafe::5b) by DM6PR07CA0044.outlook.office365.com (2603:10b6:5:74::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6134.24 via Frontend Transport; Fri, 24 Feb 2023 07:34:55 +0000 X-MS-Exchange-Authentication-Results: spf=softfail (sender IP is 66.129.239.15) smtp.mailfrom=juniper.net; dkim=none (message not signed) header.d=none;dmarc=fail action=oreject header.from=juniper.net; Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.15 as permitted sender) Received: from p-exchfe-eqx-02.jnpr.net (66.129.239.15) by DM6NAM12FT095.mail.protection.outlook.com (10.13.178.194) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6134.19 via Frontend Transport; Fri, 24 Feb 2023 07:34:55 +0000 Received: from p-exchbe-eqx-02.jnpr.net (10.104.9.15) by p-exchfe-eqx-02.jnpr.net (10.104.9.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.30; Fri, 24 Feb 2023 01:34:54 -0600 Received: from p-mailhub01.juniper.net (10.104.20.6) by p-exchbe-eqx-02.jnpr.net (10.104.9.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.30 via Frontend Transport; Fri, 24 Feb 2023 01:34:54 -0600 Received: from kaos.jnpr.net (kaos.jnpr.net [172.23.255.201]) by p-mailhub01.juniper.net (8.14.4/8.11.3) with ESMTP id 31O7YsuP001227; Thu, 23 Feb 2023 23:34:54 -0800 (envelope-from sjg@juniper.net) Received: by kaos.jnpr.net (Postfix, from userid 1377) id 9FF5C2115A; Thu, 23 Feb 2023 23:33:54 -0800 (PST) Received: from kaos.jnpr.net (localhost [127.0.0.1]) by kaos.jnpr.net (Postfix) with ESMTP id 9CB18212B7; Thu, 23 Feb 2023 23:33:54 -0800 (PST) To: Mark Millard CC: Bryan Drewery , Current FreeBSD , Peter , Subject: Re: FYI: Why META_MODE rebuilds so much for building again after installworld (no source changes) In-Reply-To: <21F1E7D4-D709-4DFF-98D6-51795B9BB291@yahoo.com> References: <3345EBA5-A09C-4E3F-B94D-39F57F56BDBB@yahoo.com> <73088.1611797582@kaos.jnpr.net> <10819.1677108389@kaos.jnpr.net> <76FA98EF-6184-4D7E-A01F-0EE8117D0D10@yahoo.com> <29887.1677115125@kaos.jnpr.net> <27790339-240F-4C97-97C7-38AFD8DE03D5@yahoo.com> <7FB6F619-6E71-4075-8A6C-573564371DD5@yahoo.com> <2655.1677134606@kaos.jnpr.net> <242BB478-B2FE-4BCC-A56E-098F3FEB3EE1@yahoo.com> <42586.1677183334@kaos.jnpr.net> <30.1677189836@kaos.jnpr.net> <1B5FCF8A-0DFD-4246-8464-65A44A40529F@yahoo.com> <93460.1677202939@kaos.jnpr.net> <17672.1677210880@kaos.jnpr.net> <21F1E7D4-D709-4DFF-98D6-51795B9BB291@yahoo.com> Comments: In-reply-to: Mark Millard message dated "Thu, 23 Feb 2023 20:57:20 -0800." From: "Simon J. Gerraty" X-Mailer: MH-E 8.6+git; nmh 1.7.1; GNU Emacs 28.1 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 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <98794.1677224034.1@kaos.jnpr.net> Date: Thu, 23 Feb 2023 23:33:54 -0800 Message-ID: <30.1677224034@kaos.jnpr.net> X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: DM6NAM12FT095:EE_|BLAPR05MB7490:EE_ X-MS-Office365-Filtering-Correlation-Id: 0115cdbb-51bc-4147-3585-08db16399ff8 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: 9JBzbuhOzkA+RR7iANWFqj7e8U4XDAl4s7kSfjRt/bSJXY3yT80BvAGNUzCW2bSV1PYmh3f5heKncE12JaJx02nDS2K/A8gZ9WrvXMkMJQjlGgyi5S0Lb5ELvRJ24TIkcxjJPYwzF5PmEPmV61K/z/mqDrTbIn8XkeKJ7gSXleWwIAs7cDmf+hbliDauEHd/j7lAs/qhvVK7ixZcT2qjUiG582CbJl4fWjiUpyNiLZhEbQ4hAAWMeYXfEVYdOKuynZX3FHiSCu7P+n9jQjWGVHq6RDhCxzyK+LxKKIjVeNTMdr1AY1DwLVyLD7mqgksVvVliczKHz/ckjGQwswQaLiGVDGuh/wZ7nytuXQkC3SOf7fq55rLLXY3xqcGOyO+jJ3x5zjYNu4YddVIWFtqIFVKZBf9o2FVR3UrDznQ8A4cgxvMJ7liLiqIi9JuUZo/7+AtspVpe0yDZinP2cFIqiRi5jXN7K2nJw2fvnwgkK9jRD2I12Xm+X/ludDosvTGe1pGFdGGeFjW9lnVWt2Z1cwD42S0MFk0AK5foWUz9lNgmlxN4RQ5/muUzkbYNbvzmuq/chptQWbrg/o8wnZM1ygBchJBDIoH4dD7seTsI7bYzUjxNpc4GKRy3cDFrn4JKOIO+QriTjuoqpD3T1tEuy1eQdPZRelixK33d/MFJ/PPrg03v/+i8an/7uQ8PJyoWVqVR1BlUsoI0NZHB/DJRo5rSOQIoQJmxpstqEFGg3YA= X-Forefront-Antispam-Report: CIP:66.129.239.15;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:p-exchfe-eqx-02.jnpr.net;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230025)(4636009)(396003)(136003)(39860400002)(346002)(376002)(451199018)(40470700004)(36840700001)(46966006)(26005)(6266002)(9686003)(186003)(107886003)(36860700001)(47076005)(82310400005)(356005)(40460700003)(86362001)(40480700001)(55016003)(81166007)(82740400003)(7126003)(336012)(41300700001)(70206006)(70586007)(4326008)(8676002)(6916009)(2906002)(8936002)(5660300002)(7696005)(478600001)(54906003)(316002)(19627235002)(36900700001);DIR:OUT;SFP:1102; X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 24 Feb 2023 07:34:55.5066 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 0115cdbb-51bc-4147-3585-08db16399ff8 X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4;Ip=[66.129.239.15];Helo=[p-exchfe-eqx-02.jnpr.net] X-MS-Exchange-CrossTenant-AuthSource: DM6NAM12FT095.eop-nam12.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLAPR05MB7490 X-Proofpoint-GUID: gI8BaIBOqA2RIg-fhiyfsJjpx6v3zOay X-Proofpoint-ORIG-GUID: gI8BaIBOqA2RIg-fhiyfsJjpx6v3zOay X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.219,Aquarius:18.0.930,Hydra:6.0.562,FMLib:17.11.170.22 definitions=2023-02-24_04,2023-02-23_01,2023-02-09_01 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 bulkscore=0 suspectscore=0 impostorscore=0 mlxscore=0 malwarescore=0 spamscore=0 phishscore=0 mlxlogscore=999 clxscore=1015 adultscore=0 priorityscore=1501 lowpriorityscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2212070000 definitions=main-2302240061 X-Rspamd-Queue-Id: 4PNMB01pLLz3F48 X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:22843, ipnet:67.231.152.0/24, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N Mark Millard wrote: > > Perhaps you want to be using > > > > .MAKE.META.IGNORE_PATHS+= ${MAKEOBJDIRPREFIX}/tmp/legacy/usr > > or is that ${MAKEOBJDIRPREFIX}/${TARGET}.${TARGET_ARCH}/tmp/legacy/usr > > > > I had started with trying to use MAKEOBJDIRPREFIX but it > appeared to end up with an empty expansion in something > I'd looked at, making the addition to > .MAKE.META.IGNORE_PATHS ineffective. > > But with the .info lines in place, I should probably > recheck an example with ${MAKEOBJDIRPREFIX} in it. > (Expecting .MAKE.META.IGNORE_PATHS to not work but > showing what happens for the MAKEOBJDIRPREFIX use.) > This turns out to be different for "modules" vs. > "pure kernel". I start with a "modules" example > below. Yes, if the value of MAKEOBJDIRPREFIX isn't consistent that's going to cause problems (I'd call it a bug). If so don't use MAKEOBJDIRPREFIX directly, set some other variable and export that. Hmm src.sys.obj.mk plays games with MAKEOBJDIRPREFIX so that's probably not a good option. Perhaps: diff --git a/share/mk/src.sys.obj.mk b/share/mk/src.sys.obj.mk index 3b48fc3c5514..3c7e570dbdbd 100644 --- a/share/mk/src.sys.obj.mk +++ b/share/mk/src.sys.obj.mk @@ -67,6 +67,9 @@ SB_OBJROOT?= ${SB}/obj/ OBJROOT?= ${SB_OBJROOT} .endif OBJROOT?= ${_default_makeobjdirprefix}${SRCTOP}/ +# save the value before we mess with it +_OBJROOT:= ${OBJROOT:tA} +.export _OBJROOT .if ${OBJROOT:M*/} != "" OBJROOT:= ${OBJROOT:H:tA}/ .else and then something like? .MAKE.META.IGNORE_PATHS += ${_OBJROOT}/${MACHINE}.${MACHINE_ARCH}/tmp/legacy/usr > and still not right (MAKEOBJDIRPREFIX expanded > to empty). See above > I still do not know notation to make .MAKE.META.IGNORE_PATHS > effective for the specific list of tmp/legacy/usr/sbin/* > examples in question. > > Effectively, it appears that the coverage of > .MAKE.META.IGNORE_PATHS is just incomplete (via the > notational constraints it is used within). No, your problem has nothing to do with .MAKE.META.IGNORE_PATHS but with the build's lack of a consistent definition of OBJTOP or OBJROOT or whatever you want to call it. You could I guess take note of .OBJDIR when setting .MAKE.META.IGNORE_PATHS and if it match */sys/compile* and tweak things accordingly so you actually get the value you want. The messing about with MAKEOBJDIRPREFIX has been around so long I don't know how you could go about fixing it at this point. FWIW in our build we make a clear distinction between things build for the "host" (all the tools you care about are actually host tools not target tools I think), and those built for a target. Everything built for host is found under ${HOST_OBJTOP} and everything for the targets is under ${OBJTOP} which we define consistently mk -V OBJTOP -V HOST_OBJTOP:tA /var/obj/FreeBSD/main/obj/amd64.amd64 /var/obj/FreeBSD/main/obj/freebsd13-amd64 (the :tA is needed there so you can see the relationship - HOST_OBJTOP comes from environment) mk -n buildworld -V OBJTOP Setting legacy build env... /var/obj/FreeBSD/main/obj/h/sjg/work/FreeBSD/main/src/amd64.amd64 and as you know, that value does not remain consistent thoughout the tree which makes it of questionable value. --sjg From nobody Fri Feb 24 20:55:56 2023 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 4PNhy75Zl3z3twSW for ; Fri, 24 Feb 2023 20:56:15 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic316-55.consmr.mail.gq1.yahoo.com (sonic316-55.consmr.mail.gq1.yahoo.com [98.137.69.31]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4PNhy70Hkbz3ryX for ; Fri, 24 Feb 2023 20:56:14 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1677272172; bh=vhRiWBB6jJHs7nmyzJOZkjp2jdPnPFdsKd/e7w0bfeI=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=PUWsiRx5WrlaZIHRGPCh2aoURt+8IFxMTuergOjYS443q3sdE0nD4okpjqb8fjDjCa6WdVq2veADDderMxj1gfAL/YY8TbsFLeaWe1/wiImRqYBm+eqY4XW9yIACENaA/LAOPhAQ2iwYdDWYqmbocSNVtlFyGObM/NI3Tzn/eddibRbpPxyZmfeHDwK2lWUWNsQxqnJKgdv8HDkBBRrXJUb7bdD97CEf+/88cfAalyfwDQOvVl7TVk+IBuCB2AIqz8g4FKt9g+NZlGEcOvUE52YMKlC6UefjT0wBPNF50iShr+0g8yXGpv1YlCCGmG7ceAbmrQcqnFfV+4oAMWjSWA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1677272172; bh=1f+r9q6Gh5i7VVxqWaqXEIWt6Iz3CuvYpPuFKXHTIcp=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=YWMi5/IktvBCRXeHTRpTXiy+7TFrV6TphDVHkVW8oaRuGt6DODoYh2dSFeiJh/VuBLg0ym4hQfbi8f9H91ME02Qul6AixEFo1BesNbIo3mcJdqHAD/zv/d/N6KopVOgPvIdtGfL9BRsHPBfmQVhwxy9u6ZlF4t1mwaKCoo9+V1tZTuuaEFM74rDx94ldG8Fyu1V4A5KTwbigKvM/8wevzja0wEtumWSJUbKWvcRcWIa+J4iTAmysZiAQ+oH6T6DqIrq8vFDdwZgflOQXylGZLGAACAKHM5TXDyBt2QlXQ4p495ZjuTJ4dNNI6oAW6NYeMF009cHY2LLdq0fiQM6jdg== X-YMail-OSG: Ai4SNGMVM1kkoKVd_IzGV6icNa1z7v.wbTLbLpwUOJ2ZuXyGAB.ETGN0GUIbcxA Vjsg0DRN_sz2NicfVWs5DA4ccF9lLY7jnDeuC8zWzQB3iidHHA01gSyD5tcWXwSTd6LM_5Ce4tpT GYLHj.xHxaI1eQBgDayS.EZueuQ8jIPMWFM930IVbxqbul6Fd.2nrE1OQCcN2zmDrp641R1p2Ly2 wKxEC1rtthvVTWA2pquAg.KB8mwcfJR505FVNR5QEhE6rz4ARlUiqy5tB.DlTmSMVXyu0QK50nr0 l1OZOHDRz3S8iQ3dHrtvU4ZjheLDFuXnS847ImnSF.BzCD6XlDbO.Yyxw9SNwe65PoRUIy1jw_Is jkcfVxBT4M3ddfzy6D8t6x5YKNvrvVEj.jZypZO5nGCyTeUBWdp9K7fAKRssqylCfkQFwMtw3R_T BAealZLBxqI66Y0fxpP4sVnFVpqa7Oepltq87vUBs73AVKedQWhG4nIW3VE4wmY.iiJsQRBG_sBk V7d7yGe5.Q.xSclEr93e1aQXPacTY6hMdZdsvyQbs4p5hpE6vbg_nAKpO.8FKp6TeRQoySK5o0Io GhZJbItEGWSpp7Oqotb0pNz_CcvINVFjjfjbt.UJ2THdpwZEecxc_gLbJOS5CyIrjTXoy9F1GQfi nMk0rDmST3gCPmnaWH6rm3cYsnmDflBU8gjdELgIs3eeRRHtYPaOzORg3em6bBvxolIjAse2CDUg XX5BsIFWWls8vG3nF5IK2zE3ql5p5y95zjm1y5d35vMDfd7JeaZotRYjSzVkxCRUxFrQ5A6aTik8 fGGGoFlpZcLfSj9mz8XhRozW7zPe45a8wXgJYUZHLMOO4s5sgtAPA34Mm93aGKOjEWWdyD95eT5V tCRY6ri86tmKXO7Cf01qM7zzcTtXWcOBs4Ir.WlMShfgBtyhPufb20wVJwtGsllJkxPplLzLXHCb dh3_jQLX.lhz1HWk0sBsrGFsaD09a4PUbHcMMrcxiNF9oSDdW2wamy5ZewFbD4pV2IdGUhxizP5k O2TyqQkpZwVlaCUTbCe5STtwJM8BbCxjSZJLOqCuGRHqKOIgRHNIeIhtcnXjkBd5F6cGIhGQa6T3 AWLGWJ16KaHvScaoDmepBfFLmQSvSWM0KIH.r60qVU6O014IOXBEj_PHIVE8puYQQVE54GCAZekW 5NDkPZs5Ix6nni_xp7qj.fIHKsIsClciK1bBpwMtoC3SaRhwB9ahLROCQorjLjZDBNLg5mqVi8pj 44g64.O.9ksCasAvAU3YfYNfkKOQkv6T5tYPQwQSHBd9l1BkE5uJnEl81KBTUhlvnfcpVvTuUrQ1 rpnHJRU_EzhmYUOacHmT2pGyqDQ4DqeCYOtLR0s5Ab_udcu2UNjjElFhTNk7r6Kb09tzPxXQakao MLhbufJF3CR0OFd1M3xFweDO7sMrBSJSl8DBQu4Rw4X4t1bfu5ztjVbhrq1K_nZgZY1paUE31IPE k._FKpMkcMlUCZs5aYBBYEuy9HCi3Z1LCN7Joog5MYDlduadp6aa.jfzWIBLdPDVlqfJrh8a.bRF U_33h4g9j7Mw8fx8mdZ7YdG4Vjiqbk.wV6CR07M5_Rneyrbuo79595Kx18ZkepfALadhyV2cEEHN ajKXYRDeft5k8OSkYEB8L9.xXI_RS_n3q95ZZ_Nw6c1nD2tvzjnCbvyWa63eedxNVUmN4ox9mMft fT9fG26K5Ock6cqc0VQ8zJvPkxj7NZLZAdyM4Noc98gLdQOzys.k6u9BemQ5CM3eK5wiyU5KutJ8 7cxlDR72Dh3gyjVvQkaDkHColuyKXjFSLCU_4MJskSFGr07p.WAm9KhECcWXGdR81EsOEKt1oaaF .MheuI2KgquNRjGVcAvzJEdGKI8R3md.oli2DmWtTUErD8iaMk2tcH120xRRokyENdY9WmA.YqjV 9D75aJHSx6gpRVd7p_syZanaIJS5SgmMFGFtT7TQZpuEa3AaNBGaMo4T.Gyys5dY7FToantLoFb2 q71JJ9O6Y09Hq9YqaT5ANhDq3KE4rslGXPRxObqwZfNz5PhlpNX.q08fO81xts6yER8pQjjRizvr utlTdvnz0Kz47tFmMpKk5lEqgolo9yM9._v7jDFuaDm8kv4fjVukL7.0.k6LAtDi938K7HnZ6NLp VAzc.cG58QlswQcy0wnbYQWik.3ZuRRrmtjXPHTsHDBYExNmeOltea0XTebT8ByVZWN6SZgghELN dkbyr.0NH2cGsuXk.KAbnnrypymEQ22H_JjfhWKKf0pqpwa2zUEj_AFhYrGV5MWo.8e2qnLLrAYh 5 X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic316.consmr.mail.gq1.yahoo.com with HTTP; Fri, 24 Feb 2023 20:56:12 +0000 Received: by hermes--production-gq1-655ddccc9-j6kw5 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID fe8696a4ed3bbcdc8b6fff021ae32dca; Fri, 24 Feb 2023 20:56:07 +0000 (UTC) Content-Type: text/plain; charset=us-ascii 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 Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.400.51.1.1\)) Subject: Re: FYI: Why META_MODE rebuilds so much for building again after installworld (no source changes) From: Mark Millard In-Reply-To: <30.1677224034@kaos.jnpr.net> Date: Fri, 24 Feb 2023 12:55:56 -0800 Cc: Bryan Drewery , Current FreeBSD , Peter Content-Transfer-Encoding: quoted-printable Message-Id: <19D6D11D-7FA0-4D86-B04C-0EE5D3AAE028@yahoo.com> References: <3345EBA5-A09C-4E3F-B94D-39F57F56BDBB@yahoo.com> <73088.1611797582@kaos.jnpr.net> <10819.1677108389@kaos.jnpr.net> <76FA98EF-6184-4D7E-A01F-0EE8117D0D10@yahoo.com> <29887.1677115125@kaos.jnpr.net> <27790339-240F-4C97-97C7-38AFD8DE03D5@yahoo.com> <7FB6F619-6E71-4075-8A6C-573564371DD5@yahoo.com> <2655.1677134606@kaos.jnpr.net> <242BB478-B2FE-4BCC-A56E-098F3FEB3EE1@yahoo.com> <42586.1677183334@kaos.jnpr.net> <30.1677189836@kaos.jnpr.net> <1B5FCF8A-0DFD-4246-8464-65A44A40529F@yahoo.com> <93460.1677202939@kaos.jnpr.net> <17672.1677210880@kaos.jnpr.net> <21F1E7D4-D709-4DFF-98D6-51795B9BB291@yahoo.com> <30.1677224034@kaos.jnpr.net> To: "Simon J. Gerraty" X-Mailer: Apple Mail (2.3731.400.51.1.1) X-Rspamd-Queue-Id: 4PNhy70Hkbz3ryX X-Spamd-Bar: ---- 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-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N On Feb 23, 2023, at 23:33, Simon J. Gerraty wrote: >=20 >> . . . >=20 > Yes, if the value of MAKEOBJDIRPREFIX isn't consistent that's going to > cause problems (I'd call it a bug). If so don't use MAKEOBJDIRPREFIX > directly, set some other variable and export that. > Hmm src.sys.obj.mk plays games with MAKEOBJDIRPREFIX so that's > probably not a good option. > Perhaps: >=20 > diff --git a/share/mk/src.sys.obj.mk b/share/mk/src.sys.obj.mk > index 3b48fc3c5514..3c7e570dbdbd 100644 > --- a/share/mk/src.sys.obj.mk > +++ b/share/mk/src.sys.obj.mk > @@ -67,6 +67,9 @@ SB_OBJROOT?=3D ${SB}/obj/ > OBJROOT?=3D ${SB_OBJROOT} > .endif > OBJROOT?=3D ${_default_makeobjdirprefix}${SRCTOP}/ > +# save the value before we mess with it > +_OBJROOT:=3D ${OBJROOT:tA} > +.export _OBJROOT > .if ${OBJROOT:M*/} !=3D "" > OBJROOT:=3D ${OBJROOT:H:tA}/ > .else >=20 > and then something like? >=20 > .MAKE.META.IGNORE_PATHS +=3D > ${_OBJROOT}/${MACHINE}.${MACHINE_ARCH}/tmp/legacy/usr >=20 >> . . . >=20 Thanks. That has allowed me to set up the disabling of specific . . ./tmp/legacy/usr/sbin/* programs from having their dates lead directly to rebuild activity (tested via -dM use in the make commands). For reference, I'm using the below block of text for the .MAKE.META.IGNORE_PATHS adjustments now. # _OBJROOT is an addition to share/mk/src.sys.obj.mk # provided by Simon J. Gerraty for my experimentation # with this avoidance of some unnecessary build # activity in META MODE: # # OBJROOT?=3D ${_default_makeobjdirprefix}${SRCTOP}/ # +# save the value before we mess with it # +_OBJROOT:=3D ${OBJROOT:tA} # +.export _OBJROOT # # TARGET.TARGET_ARCH for amd64 stays as amd64.amd64 for obj-lib32 = (correct for the purpose) # MACHINE.MACHINE_ARCH for amd64 turns into i386.i386 for obj-lib32 = (wrong for the purpose) # IGNORELEGACY_NOSYMLINKPREFIX=3D = ${_OBJROOT}/${TARGET}.${TARGET_ARCH}/tmp/legacy/usr IGNOREOTHER_NOSYMLINKPREFIX=3D = ${_OBJROOT}/${TARGET}.${TARGET_ARCH}/tmp/usr/bin # .for ignore_legacy_tool in awk basename cap_mkdb cat chmod cmp cp = crunchgen crunchide cut date dd dirname echo egrep env expr fgrep file2c = find gencat grep gzip head hostname jot lex lb ln ls m4 make mkcsmapper mkdir mktemp mtree mv nawk patch realpath rm sed sh sort = touch tr truncate uudecode uuencode wc xargs .MAKE.META.IGNORE_PATHS+=3D = ${IGNORELEGACY_NOSYMLINKPREFIX}/sbin/${ignore_legacy_tool} .endfor # .for ignore_other_tool in ctfconvert objcopy nm .MAKE.META.IGNORE_PATHS+=3D = ${IGNOREOTHER_NOSYMLINKPREFIX}/${ignore_other_tool} .endfor # .MAKE.META.IGNORE_PATHS:=3D ${.MAKE.META.IGNORE_PATHS} (It is in a file specified via env __MAKE_CONF=3D use.) I've extended the experiment to span releng/13.0 , releng/13.1 , stable/13 as well, not just main [so: 14]. And I've set up the aarch64 environment as well for that range of system variations. (It also builds for targeting armv7 which is also covered.) We will see how it goes as I track system updates periodically. Thanks again. For reference, the -dM "is newer than" notice counts in the log for a buildworld buildkernel just after a installworld installkernel now looks like: 1467 file = '/usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/tmp/usr/l= ib/Scrt1.o' is newer than the target... 515 file = '/usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/tmp/usr/l= ib/crti.o' is newer than the target... 236 file = '/usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/tmp/usr/l= ib32/crti.o' is newer than the target... 70 file = '/usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/tmp/usr/l= ib/libgcc_s.so' is newer than the target... 69 file = '/usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/tmp/usr/l= ib32/libgcc_s.so' is newer than the target... 68 file = '/usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/tmp/usr/l= ib/crt1.o' is newer than the target... 3 file = '/usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/tmp/usr/i= nclude/aio.h' is newer than the target... 1 file = '/usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/tmp/usr/l= ib32/libssl.so' is newer than the target... 1 file = '/usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/tmp/usr/l= ib32/libcxxrt.so' is newer than the target... 1 file = '/usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/tmp/usr/l= ib32/libctf.so' is newer than the target... 1 file = '/usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/tmp/usr/l= ib32/libcrypto.so' is newer than the target... 1 file = '/usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/tmp/usr/l= ib32/libc.so.7' is newer than the target... 1 file = '/usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/tmp/usr/l= ib32/Scrt1.o' is newer than the target... 1 file = '/usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/tmp/usr/l= ib/libssl.so' is newer than the target... 1 file = '/usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/tmp/usr/l= ib/libcxxrt.so' is newer than the target... 1 file = '/usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/tmp/usr/l= ib/libctf.so' is newer than the target... 1 file = '/usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/tmp/usr/l= ib/libcrypto.so' is newer than the target... 1 file = '/usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/tmp/lib/l= ibc.so.7' is newer than the target... Doing another buildworld buildkernel just after and looking at its log's counts looks very similar. (No claim of what the likes of, say, a clang14 -> clang15 based system update would be like overall: the above is for the study-state of no source updates being involved.) =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Fri Feb 24 21:05:02 2023 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 4PNj8R1PtMz3twXc; Fri, 24 Feb 2023 21:05:11 +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 "www.zefox.com", Issuer "www.zefox.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4PNj8Q2BQcz3tBQ; Fri, 24 Feb 2023 21:05:10 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Authentication-Results: mx1.freebsd.org; dkim=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; dmarc=none Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.17.1/8.15.2) with ESMTPS id 31OL53v4008207 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Fri, 24 Feb 2023 13:05:03 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.17.1/8.15.2/Submit) id 31OL53w4008206; Fri, 24 Feb 2023 13:05:03 -0800 (PST) (envelope-from fbsd) Date: Fri, 24 Feb 2023 13:05:02 -0800 From: bob prohaska To: freebsd-current@freebsd.org Cc: freebsd-arm@freebsd.org Subject: Timekeeping problem in /usr/src on new RPI aarch64 snapshot Message-ID: <20230224210502.GA8127@www.zefox.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 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spamd-Result: default: False [-0.69 / 15.00]; AUTH_NA(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-0.999]; NEURAL_HAM_SHORT(-0.59)[-0.594]; MID_RHS_WWW(0.50)[]; WWW_DOT_DOMAIN(0.50)[]; MIME_GOOD(-0.10)[text/plain]; FROM_EQ_ENVFROM(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US]; R_SPF_NA(0.00)[no SPF record]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org,freebsd-arm@freebsd.org]; RCPT_COUNT_TWO(0.00)[2]; ARC_NA(0.00)[]; TO_DN_NONE(0.00)[]; FROM_HAS_DN(0.00)[]; DMARC_NA(0.00)[zefox.net]; RCVD_COUNT_THREE(0.00)[3]; RCVD_TLS_LAST(0.00)[]; MID_RHS_MATCH_FROM(0.00)[] X-Rspamd-Queue-Id: 4PNj8Q2BQcz3tBQ X-Spamd-Bar: / X-ThisMailContainsUnwantedMimeParts: N After installing FreeBSD-14.0-CURRENT-arm64-aarch64-RPI-20230223-fe5c211ba873-261074.img on a Pi3 and setting up the hard disk to use separate swap and /usr partitions an oddity came to light regarding dates. The image file was written to disk the night of the 23rd, from a Pi3 with a correctly-set time and date. It was left idle overnight, configured the morning of the 24th and booted without issue. It then cloned -current into /usr/src, at which point the time was noticed to be wrong, apparently fast. It turned out ntpdate wasn't running, so it was started and then tzsetup run. After a reboot the time reported correctly. However, make buildworld in /usr/src triggers an exhortation to "check your time" and refuses run further. running date on the system reports Fri Feb 24 12:49:41 PST 2023 but ls -l /usr/src reports time around Feb 24 19:10 an obvious inconsistency. Presumably just waiting until the system clock catches up with the /usr/src timestamps will fix the error. Is there a better method? Still, the date and time handling don't seem quite right. In at least one earlier instance it appeared that tzsetup altered the reported timeszone without shifting the time stamp by the UTC/PDT offset. I always thought timestamps were internally in UTC+timezone, displayed with the right offset. It looks to a casual observer like something else is going on. An earlier fiasco (on this same Pi3) included wildly wrong timestamps in a filesystem. The Pi3 has no hardware clock, how does it set time when booted without a reference? Thanks for reading, bob prohaska From nobody Fri Feb 24 21:52:48 2023 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 4PNkCf1Lyqz3v05Z for ; Fri, 24 Feb 2023 21:53:02 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic316-55.consmr.mail.gq1.yahoo.com (sonic316-55.consmr.mail.gq1.yahoo.com [98.137.69.31]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4PNkCf01g8z4206 for ; Fri, 24 Feb 2023 21:53:01 +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=1677275579; bh=c8rpSQm39LKxmY7wLZwap7TztJClQlXvdFlQsGXHPe8=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=AVs/Z08lq7Z+1Ig9rsAIWRdSbDHE8GRtcY6eISEcQ9k6gibcfiqipXiXzl0wlW69EgmM+tRiq72vL4FyEejz7RTTN4N0sVV5bgO0Iwnh27Ap0hULh3YBOc3ERCf76dAmEdz4ynpUoNtMbtO3BZD/+iXwHj5IebZc3zbCjWY8iL49oYoc0ShPhSKFjBLJhgdD2wKMzeZLrc8Wkz3FN1s3C8d9R+uXthAzSwdX+j64IDb3i4bpVoyLdN9f2Q89dMgpsrZjDBOWUy/3dw332p++Ye4yaHomoEJ9qC82xS2ZsdF4quzgFbEh7Hhsa4rUeQOj0tENRQGN95sdptgCkwl4tA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1677275579; bh=9DFmdAMg+4SwQb2EcHxH9he09GsE7DfmawB1mNMwyfD=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=l27p5sw+prnLHVsqWN7/W1r+mAOeher/pb4Fze3FVsBuS9J/hGRNGHy+yEKcOME7ncVrmakUPHlaYSjkv5gTAyRa/7zCB+b3BoBJh/EIWemspFOID/I/UwjV1JAim4Vm8RsqfeltIppb5vb5URHEwTZSOK0pWEv+/Sh4IDEvIh5H4cb2Aktl0HyKE4Kl91w2xatxPRijT3rkOqCRfhVEDdTQClBfbrRfTFDLPE5juHHrBzC1Rxf5Y9HfI1IbnKNejp3waLYp8Qq/xXkV9abu3pw3v5dzxgwKIaF66josjVBDXhEQmvhmb3VVBgvtvByTT86LuCCQEMgKlFfY5v8X2w== X-YMail-OSG: i2YYsXoVM1ltLSDr5p00_k23L6klgBQ1W4UYPzQ7Fh9N1oFChYOoC40D3ODbVmd H02FanCFNM6LFyCSCoeA_Bhvgz5t9pkwFfTa6h.hjX6t9nws4dBUuQwnjO0hpDiGm_ZgZFCFRj36 BbBBP_2TedUzZhAEoByTHRqH.13yg86ES.G8m27c7gMNqnV5kh0nYev2uT1OyezUp94Kljnhegyy sO5zeuFGBKpeT_s_lH86quuJ3ESj7v5_TJtQ0P7.Jkjugy_AH2yayr0uqLs6nfWb1C8z9pcl6sS_ UnjYvIvXDUK56UjMyKj46MZw.GCHtVHg60Qr9myc1LicSbIQtO_QrBBEFYKCkYdb0JY8Yz4ogCmg 3j0MLlUrApu_vC0Q2Or6.qt2d3ZhWtagdri2BnDRcRRpyA7lHRdkD2k1W.tbT_f8Mjo_dRJBFlzq RpFHnS.AxfeB_1xn8EUZzZpK47hDnYGbog8GREHNMmEPELZFMTqoCyg8N6H8ZcG5au0OgG.Qk8cP 4au7Sj3Cq5XpkKFwwa7_JpS2vbmeJU5Qs9Uo9axwGzSpRibR8l1lmyeu5lI9QW_NraB8qqaD9HlV amfUfDWaDAWm80va_6t7.UIw1BWUeAhtY0SGNLA25VvPEzByBzKgPu.Ow.7g31wu97wdNo7m2J22 33.gO6gpuq6ysJyq548DnO1FfdYBlM3pwPE0Noad4qLH2SNuSQsuniGMKA3G6JwC8pA877StAXVG P6obuWus3lEVdnI8FowvXpkOB4dk7ktp9ZhEyKGRcEWlpICudccc2tPoGOXjPfJDgZAqKvnCqTNR AQFx4bbbS6N1IIYLQlxnq6JvZoGUVV3kZquxpgynQcTSjTg97ry_UoRkHqs0d84Ab6pRzylaW5gi 2xBqrgDv9IBIBjnIiZBR0Rz5lfhj4yaXnHOwZYk1HPaC0mAQTObreVZ9bl9VRu8d27raRUxqw9FB 6ty2j7Oix09c2BngFr.Bbnnvyr0KtEQdQTzxN3Xp7DcKuLyKmoWDTZtjvMeML.FtiH16MlqStiWp Yzwi9fFCq45ERxBFve7VB_.IJslEfiVfAUZ.mCWYrvkBlWXnUq0MXaOrfV_HGmBhZV6veHlrC244 QiVbdylXnpYgAGGIq7dI0UFknhl4rTzcbxiS5d1JVgcamRIj7yT8XBOo_lmhMcWKKLOE_ANrCiQy 3Yaya_0Y_47A0w2lGRfNHrdLmOOplCHrlLZng2nwKjZ6wEPRTKwTECH5K.bVj7Y2Hvp2krHdWblE gSvZHcS8Rw_Zcj3qgZ3eLawhIVxzZHZ5sl8XCA2kfPukjqLYRcQ1z4PSneVvSPmvMSkES0BpyfBV E_Xd7JvoTPGYxkDfzhaf_wOzWvD8gtLXRosv0AQAsj94U08GhLQ7uyS1ZU2caBcpSLi7abSlmSeR Dbw4beEo1VCZ66W8O5FZIPV2KAKh_5KsJ4.qWz5.46j2Q7NKt_mLmL5oDx1U5pW3jRtxlhvUyS3f IFNOxjhZWqRajxVSxW59BVDtt57iJgDJDebTJBR4ZaiH07GqrekScDAKF0UbOpaE9uZyG8DM5wCo Q5x.Vn6ioqXVmz9JLgCoIv4yVyEdszwz03QuUEpJkMv84.1WfqYXfcxkNNXhKHQz.kkvtGxkZ1bV iM83D0xJ6pVGfqeQyzGbH2wz2ocdvns5.LjCg7EwYqYeQp2zjigyi7KpNuJB1iM_lAO2M3UPuEoG ZwYK4mrefRrH4IK0EwiO68kqpl7mesm2Y2nrjRsK4AauYk2veTYBMd8HJeNzxjjIi7ICbUm49ouj nxDUtNEdScxBAdmXvjbGPl6ZwKQK8rp7ZVEGLXcoZL0uWQmtKbL7slz8nlhweSvnxGrKcGgg1dYN Ap06ruHydLDUxLGISSEJG.NLMQZhRuebO4Lpm.JrOasi.KGq80xv3vJ.KtHehRdSp2ohmmB3dPlC 3R0ocNSPLW1uXfdF1XmMzsSDVILVst9CpTfvqvRa8fJal9uSagZxCSvwa1XW5PRWm24Tb.aB2B5u zr_D5MKNIRQ9zdENSmMiJqkgrO0qCuX8Oh8AKvMT2ppDfi4BFdqHWR1OEXZfXK3FqOalg17BYXhg PXVrlWB8VbOHCF0jeWEmtkZuYE80EAHg8KFVgPBzlCGAulXuc9v_lxbTqQPG9fnO9EIpM6Xe54Fh n408Z42vrA9m36V6wQk7TL8O1ARcFV6uAvAqY0VlS3.DoA5Qq151ij51ExRV78jqmzyN4wWlSApd nLTw.mYPJzA6ji4zA02zwYR3YPkxxoFyBOWCM3GcohNpTxhRWG72H_zX4URzERKFmjsQxcpFflze s X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic316.consmr.mail.gq1.yahoo.com with HTTP; Fri, 24 Feb 2023 21:52:59 +0000 Received: by hermes--production-gq1-655ddccc9-nql2v (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 7c31e287324c0c661d251f2dfc915b40; Fri, 24 Feb 2023 21:52:58 +0000 (UTC) Content-Type: text/plain; charset=us-ascii 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 Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.400.51.1.1\)) Subject: Re: Timekeeping problem in /usr/src on new RPI aarch64 snapshot From: Mark Millard In-Reply-To: <20230224210502.GA8127@www.zefox.net> Date: Fri, 24 Feb 2023 13:52:48 -0800 Cc: Current FreeBSD , freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <20230224210502.GA8127@www.zefox.net> To: bob prohaska X-Mailer: Apple Mail (2.3731.400.51.1.1) X-Rspamd-Queue-Id: 4PNkCf01g8z4206 X-Spamd-Bar: ---- 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-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N On Feb 24, 2023, at 13:05, bob prohaska wrote: > After installing=20 > = FreeBSD-14.0-CURRENT-arm64-aarch64-RPI-20230223-fe5c211ba873-261074.img > on a Pi3 and setting up the hard disk to use separate swap and /usr = partitions > an oddity came to light regarding dates. >=20 > The image file was written to disk the night of the 23rd, from a Pi3 = with > a correctly-set time and date. It was left idle overnight, configured = the > morning of the 24th and booted without issue. It then cloned -current = into > /usr/src, at which point the time was noticed to be wrong, apparently = fast. >=20 > It turned out ntpdate wasn't running, so it was started and then = tzsetup > run. After a reboot the time reported correctly.=20 >=20 > However, make buildworld in /usr/src triggers an exhortation to "check > your time" and refuses run further.=20 >=20 > running date on the system reports > Fri Feb 24 12:49:41 PST 2023 > but ls -l /usr/src reports time around=20 > Feb 24 19:10 > an obvious inconsistency. >=20 > Presumably just waiting until the system clock catches > up with the /usr/src timestamps will fix the error. Is > there a better method? >=20 > Still, the date and time handling don't seem quite right.=20 > In at least one earlier instance it appeared that tzsetup=20 > altered the reported timeszone without shifting the time > stamp by the UTC/PDT offset. I always thought timestamps > were internally in UTC+timezone, displayed with the right > offset. It looks to a casual observer like something else > is going on.=20 >=20 > An earlier fiasco (on this same Pi3) included wildly wrong > timestamps in a filesystem. The Pi3 has no hardware clock, > how does it set time when booted without a reference? There are 2 files involved: /etc/localtime Current zoneinfo file, see tzsetup(8) and = zic(8). /etc/wall_cmos_clock Empty file. Its presence indicates that the machine's CMOS clock is set to local time, = while its absence indicates a UTC CMOS clock. An oddity here is that there is no existing CMOS clock but the /etc/wall_cmos_clock status still has consequences, as I remember. Various related man pages are: adjkerntz(8) tzseteup(8) zic(8) =46rom an RPi4B: # ls -Tld /etc/wall_cmos_clock ls: /etc/wall_cmos_clock: No such file or directory # sysctl machdep.wall_cmos_clock machdep.wall_cmos_clock: 0 (So: As if a CMOS clock was using UTC time.) # strings /etc/localtime | tail -1 PST8PDT,M3.2.0,M11.1.0 # sysctl machdep.adjkerntz machdep.adjkerntz: 0 # date Fri Feb 24 13:42:52 PST 2023 (Matching the local time.) So, as configured, /etc/localtime is used to specify covert kernel UTC to local time as needed: no addition non-zero offsets. As I remember, things can be odd with file systems from Windows variants and the time stamps interpretation. Keeping such matching vs. not can get into the choice of if /etc/wall_cmos_clock is to exist or not. It can be a seprate issue if time tracking is off rate or some such. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Fri Feb 24 23:21:09 2023 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 4PNm9N0Gxvz3v49p; Fri, 24 Feb 2023 23:21:12 +0000 (UTC) (envelope-from SRS0=RvKr=6U=klop.ws=ronald-lists@realworks.nl) Received: from smtp-relay-int.realworks.nl (smtp-relay-int.realworks.nl [194.109.157.24]) (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 4PNm9M5KCLz4Fft; Fri, 24 Feb 2023 23:21:11 +0000 (UTC) (envelope-from SRS0=RvKr=6U=klop.ws=ronald-lists@realworks.nl) Authentication-Results: mx1.freebsd.org; none Date: Sat, 25 Feb 2023 00:21:09 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=klop.ws; s=rw2; t=1677280870; 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; bh=slq6LhIvHBK8955ssKcR8rkKQwtEeLy4YJK1j6RDNnc=; b=aPjEKoZHReZ8/mFDYRPb2uLRe8wh4Lza4tDIazJbJPoM/BDC69+eLanc0HZJjfPn54EOE3 gf9hNzD+VG07OECsrrahcFkMIREF2BfAKKKFJ2oqDUp6wA9Q2sPZ67vYfSHcWFcgxxIZx5 eLZDNqljrTrjc5YMAvClOhSKzAgfCIaR1bRlz4wK9l2wP+jvSSYWKZFETfuM2XM+TwD97B epv8J1/Sas5YSoA3W++I2SO3vfFiXe+qWxc5RrG+oYgi9+8AnQllcLTAZWno+/KQEGV4ZS iRHIBoUCWUwkdr0PQ4vkhmaeDWHSW489Aj8rdIBoyzopKLWwsqSgmP2MZDEhCw== From: Ronald Klop To: freebsd-arm@freebsd.org, bob prohaska , freebsd-current@freebsd.org Message-ID: <1216867532.11893.1677280869319@localhost> In-Reply-To: <20230224210502.GA8127@www.zefox.net> Subject: Re: Timekeeping problem in /usr/src on new RPI aarch64 snapshot 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 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_11892_113718381.1677280869315" X-Mailer: Realworks (645.67) Importance: Normal X-Priority: 3 (Normal) X-Rspamd-Queue-Id: 4PNm9M5KCLz4Fft X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:3265, ipnet:194.109.0.0/16, country:NL] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N ------=_Part_11892_113718381.1677280869315 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Van: bob prohaska Datum: 24 februari 2023 22:05 Aan: freebsd-current@freebsd.org CC: freebsd-arm@freebsd.org Onderwerp: Timekeeping problem in /usr/src on new RPI aarch64 snapshot >=20 >=20 > After installing=20 > FreeBSD-14.0-CURRENT-arm64-aarch64-RPI-20230223-fe5c211ba873-261074.img > on a Pi3 and setting up the hard disk to use separate swap and /usr parti= tions > an oddity came to light regarding dates. >=20 > The image file was written to disk the night of the 23rd, from a Pi3 with > a correctly-set time and date. It was left idle overnight, configured the > morning of the 24th and booted without issue. It then cloned -current int= o > /usr/src, at which point the time was noticed to be wrong, apparently fas= t. >=20 > It turned out ntpdate wasn't running, so it was started and then tzsetup > run. After a reboot the time reported correctly.=20 >=20 > However, make buildworld in /usr/src triggers an exhortation to "check > your time" and refuses run further.=20 >=20 > running date on the system reports > Fri Feb 24 12:49:41 PST 2023 > but ls -l /usr/src reports time around=20 > Feb 24 19:10 > an obvious inconsistency. > =20 > Presumably just waiting until the system clock catches > up with the /usr/src timestamps will fix the error. Is > there a better method? >=20 > Still, the date and time handling don't seem quite right.=20 > In at least one earlier instance it appeared that tzsetup=20 > altered the reported timeszone without shifting the time > stamp by the UTC/PDT offset. I always thought timestamps > were internally in UTC+timezone, displayed with the right > offset. It looks to a casual observer like something else > is going on.=20 >=20 > An earlier fiasco (on this same Pi3) included wildly wrong > timestamps in a filesystem. The Pi3 has no hardware clock, > how does it set time when booted without a reference? >=20 > Thanks for reading, >=20 > bob prohaska >=20 >=20 >=20 >=20 >=20 >=20 UFS stores the current timestamp in the superblock of the FS on clean shutd= own/unmount. On boot it reads the time from the timestamp in the superblock= of the root FS. Of coarse this timestamp is behind for the duration that t= he machine was off or rebooting so you need to adjust that using ntp.=20 For ZFS root you can use the fakertc port to do something similar.=20 You can use the command =E2=80=9Ctouch=E2=80=9C to manipulate the time of y= our /usr/src dir.=20 Regards, Ronald ------=_Part_11892_113718381.1677280869315 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Van: bob prohaska &= lt;fbsd@www.zefox.net>
Datum: 24 februari 2023 22:05=
Aan: freebsd-current@freebsd.org
CC: freebsd-arm@freebsd.org
Onderwerp: Timekeeping probl= em in /usr/src on new RPI aarch64 snapshot

After installing
FreeBSD-14.0-CURRENT-arm64-aarch64-RPI-20230223-fe5c211ba873-261074.img
on a Pi3 and setting up the hard disk to use separate swap and /usr partiti= ons
an oddity came to light regarding dates.

The image file was written to disk the night of the 23rd, from a Pi3 with a correctly-set time and date. It was left idle overnight, configured the morning of the 24th and booted without issue. It then cloned -current into<= br> /usr/src, at which point the time was noticed to be wrong, apparently fast.=

It turned out ntpdate wasn't running, so it was started and then tzsetup run. After a reboot the time reported correctly.

However, make buildworld in /usr/src triggers an exhortation to "check
your time" and refuses run further.

running date on the system reports
Fri Feb 24 12:49:41 PST 2023
but ls -l /usr/src reports time around
Feb 24 19:10
an obvious inconsistency.
 
Presumably just waiting until the system clock catches
up with the /usr/src timestamps will fix the error. Is
there a better method?

Still, the date and time handling don't seem quite right.
In at least one earlier instance it appeared that tzsetup
altered the reported timeszone without shifting the time
stamp by the UTC/PDT offset. I always thought timestamps
were internally in UTC+timezone, displayed with the right
offset. It looks to a casual observer like something else
is going on.

An earlier fiasco (on this same Pi3) included wildly wrong
timestamps in a filesystem. The Pi3 has no hardware clock,
how does it set time when booted without a reference?

Thanks for reading,

bob prohaska



UFS stores the current timestamp in the superblock of the = FS on clean shutdown/unmount. On boot it reads the time from the timestamp = in the superblock of the root FS. Of coarse this timestamp is behind for th= e duration that the machine was off or rebooting so you need to adjust that= using ntp. 
For ZFS root you can use the fakertc port to do somet= hing similar. 

You can use the command =E2=80= =9Ctouch=E2=80=9C to manipulate the time of your /usr/src dir. 
Regards,
Ronald

------=_Part_11892_113718381.1677280869315-- From nobody Sat Feb 25 08:35:36 2023 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 4PP0Tr6dtMz3ssRK; Sat, 25 Feb 2023 08:36:16 +0000 (UTC) (envelope-from freebsd@walstatt-de.de) Received: from smtp6.goneo.de (smtp6.goneo.de [IPv6:2001:1640:5::8:31]) (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 4PP0Tq0pzmz44GB; Sat, 25 Feb 2023 08:36:14 +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=VuFoLQlG; spf=none (mx1.freebsd.org: domain of freebsd@walstatt-de.de has no SPF policy when checking 2001:1640:5::8:31) smtp.mailfrom=freebsd@walstatt-de.de; dmarc=none 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 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by smtp6.goneo.de (Postfix) with ESMTPS id AADE410A0166; Sat, 25 Feb 2023 09:36:06 +0100 (CET) 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 (2048 bits)) (No client certificate requested) by hub1.goneo.de (Postfix) with ESMTPS id CD24310A1E83; Sat, 25 Feb 2023 09:36:04 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=walstatt-de.de; s=DKIM001; t=1677314164; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=c/yDwDJ2pxrlSLY6/QUTqk66AWg2tlk3I2Vgwr0wbF0=; b=VuFoLQlGmY/H/CpuOd27I95En2bbvU/Jqo1TPrfakc/kspFm3BxdKux+3AlajttRuhYfaD pvVRSRTDyGZEXvzhcElLZW8tUD0NPuORH1q5XlvxB3jrQKdafdOsZPR7UItxRmKVM0cDG5 3CfnNZyoGOEOQzff77iJPdbZwDuSijufyikJCUXrfuKl+DEgorfRE2pN+2RO4IgJBG144a 58t+dQomjbn2s3rPUBhArfjc3lED1J44QdnVxSLDltgA5w9QoPLM1qmKdWXf3ArM9PaV1A lFRuQbCAYQ7R0jTQn+dY2a8cUDW4Odtz638KeDMt/2WOYaIErOyJdebZ/kEBYA== Received: from thor.intern.walstatt.dynvpn.de (dynamic-078-055-115-118.78.55.pool.telefonica.de [78.55.115.118]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by hub1.goneo.de (Postfix) with ESMTPSA id 8E77010A32F4; Sat, 25 Feb 2023 09:36:04 +0100 (CET) Date: Sat, 25 Feb 2023 09:35:36 +0100 From: FreeBSD User To: FreeBSD CURRENT Cc: freebsd-x11@freebsd.org Subject: 13-STABLE: crashing on graphical clients (Firefox, Librewolf, GIMP et cetera) Message-ID: <20230225093603.72900a27@thor.intern.walstatt.dynvpn.de> Organization: walstatt-de.de 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 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-UID: db28bb X-Rspamd-UID: 7169ac X-Spamd-Result: default: False [-3.30 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[walstatt-de.de:s=DKIM001]; MIME_GOOD(-0.10)[text/plain]; RCVD_VIA_SMTP_AUTH(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org,freebsd-x11@freebsd.org]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; MIME_TRACE(0.00)[0:+]; DKIM_TRACE(0.00)[walstatt-de.de:+]; HAS_ORG_HEADER(0.00)[]; ASN(0.00)[asn:25394, ipnet:2001:1640::/32, country:DE]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; RCVD_COUNT_THREE(0.00)[4]; TO_DN_SOME(0.00)[]; DMARC_NA(0.00)[walstatt-de.de]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCVD_TLS_ALL(0.00)[] X-Rspamd-Queue-Id: 4PP0Tq0pzmz44GB X-Spamd-Bar: --- X-ThisMailContainsUnwantedMimeParts: N Hallo everybody, a week ago I compiled a new 13-STABLE (FreeBSD 13.2-STABLE #77 stable/13-n254681-44a6088278ea: Sat Feb 25 07:44:36 CET 2023 amd64, custom kernel, same happens with the recent regular GENERIC kernel). ZFS root installation. Graphics driver: drm-510-kmod-5.10.163_2 graphics/drm-510-kmod libdrm-2.4.115,1 graphics/libdrm xf86-video-intel-2.99.917.916_3,1 x11-drivers/xf86-video-intel Hardware: Lenovo T560, 16 GB RAM, : [...] CPU: Intel(R) Core(TM) i7-6600U CPU @ 2.60GHz (2800.00-MHz K8-class CPU) Origin="GenuineIntel" Id=0x406e3 Family=0x6 Model=0x4e Stepping=3 Features=0xbfebfbff Features2=0x7ffafbff AMD Features=0x2c100800 AMD Features2=0x121 Structured Extended Features=0x29c6fbf Structured Extended Features3=0xbc002e00 XSAVE Features=0xf IA32_ARCH_CAPS=0xc04 VT-x: PAT,HLT,MTF,PAUSE,EPT,UG,VPID TSC: P-state invariant, performance statistics real memory = 17179869184 (16384 MB) avail memory = 16462184448 (15699 MB) CPU microcode: no matching update found Event timer "LAPIC" quality 600 ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs FreeBSD/SMP: 1 package(s) x 2 core(s) x 2 hardware threads random: registering fast source Intel Secure Key RNG random: fast provider: "Intel Secure Key RNG" random: unblocking device. ioapic0 irqs 0-119 Launching APs: 1 3 2 random: entropy device external interface kbd1 at kbdmux0 efirtc0: efirtc0: registered as a time-of-day clock, resolution 1.000000s smbios0: at iomem 0xd7064000-0xd706401e smbios0: Version: 2.8, BCD Revision: 2.8 aesni0: acpi0: [...] GPU: [...] drmn0: on vgapci0 vgapci0: child drmn0 requested pci_enable_io vgapci0: child drmn0 requested pci_enable_io [drm] Unable to create a private tmpfs mount, hugepage support will be disabled(-19). [drm] Got stolen memory base 0xda800000, size 0x2000000 drmn0: could not load firmware image 'i915/skl_dmc_ver1_27.bin' drmn0: [drm] Failed to load DMC firmware i915/skl_dmc_ver1_27.bin. Disabling runtime power management. drmn0: [drm] DMC firmware homepage: https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/i915lkpi_iic0: on drmn0 iicbus0: on lkpi_iic0 iic0: on iicbus0 lkpi_iic1: on drmn0 iicbus1: on lkpi_iic1 iic1: on iicbus1 lkpi_iic2: on drmn0 iicbus2: on lkpi_iic2 iic2: on iicbus2 sysctl_warn_reuse: can't re-use a leaf (hw.dri.debug)! lkpi_iic3: on drm1 iicbus3: on lkpi_iic3 iic3: on iicbus3 lkpi_iic4: on drm2 iicbus4: on lkpi_iic4 iic4: on iicbus4 lkpi_iic5: on drm4 iicbus5: on lkpi_iic5 iic5: on iicbus5 [drm] Initialized i915 1.6.0 20200917 for drmn0 on minor 0 VT: Replacing driver "efifb" with new "fb". start FB_INFO: type=11 height=1080 width=1920 depth=32 pbase=0xe0000000 vbase=0xfffff800e0000000 name=drmn0 flags=0x0 stride=7680 bpp=32 end FB_INFO [...] Phenomena: - WindowMaker (wmaker) crashes on startup - while using blackbox or twm working, windowmanager starts, but: running any(!) larger X11 client - singleuser mode or console mode without graphics is all right There is NO coredump, nor does the kernel jump into kernel debugging although I tried to configure that. Regards and thanks in advance, oh -- O. Hartmann From nobody Sat Feb 25 15:47:17 2023 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 4PPB3Q5P19z3tJsW for ; Sat, 25 Feb 2023 15:47:30 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ed1-x52b.google.com (mail-ed1-x52b.google.com [IPv6:2a00:1450:4864:20::52b]) (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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4PPB3P4zNpz3J82 for ; Sat, 25 Feb 2023 15:47:29 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20210112.gappssmtp.com header.s=20210112 header.b="1Vp/CGrD"; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2a00:1450:4864:20::52b) smtp.mailfrom=wlosh@bsdimp.com; dmarc=none Received: by mail-ed1-x52b.google.com with SMTP id o12so8833313edb.9 for ; Sat, 25 Feb 2023 07:47:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20210112.gappssmtp.com; s=20210112; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=tO0UEZOM9D6HrCbqnm3xxnSbk7MPKw9i7ftTPLEZ32E=; b=1Vp/CGrD3yRw6ZxU9IVjIeoH4kPDSebuM+Rp0kXuU0r091swKf9uVPYoiHcYWH125p q5LzJ7ks+kYpdW7+ZWBYcjB8Qsqe78/om2LLW3/lXaSf/7ksetWTJqFby2HOeJvd8I92 cr5JSVNoNqWgp+Sd9fFl0QrxpRp1ogbO4+ohnOrwJbtfnl8dmH/lp42C+5Ruv0H/uuLs sBTPZSjNstWEPutf4QywAFo8q9LnS4Z8O5pp03Iw3x95H/mHkbV4BfMKjIQnP9mtdx5y TLn7o463epXuuja7ULB+9Tb2ZOeNtm8YdVYZqCtIlCjvHDD5abe9zfcnZbUa91WV8rjD XCIQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=tO0UEZOM9D6HrCbqnm3xxnSbk7MPKw9i7ftTPLEZ32E=; b=22mvxtsqyet2JndnEASVMkTxGiRc5rfhZB0TuA5RGRCSPiKiJy2iF3nX1barIbfPv7 qYttCU4UgQlzlLCItn440ys4WF0rjbkgXn7I+zeOmZLSQTtwlDnrdqDUuzV1Hr+T1NeQ 3Q8OtlVRlOzDkJlus1SAdzHp69ADBT3Ydi0PFu/UlBnMMcbMhROHkxkaxPJRYpo37VZk M4x+0iyQNdx7cDzCS8DY6poZRlWDx6KOMQ3Dbcm4Z/BPWt1yI6x/B7tPznFS2FWWkRkk /mj8y5FzfWxb9bCjNOknxouCvT7V47uSSWfRsAagg0teH0abf93g0erRQHNZV45E6wE4 xhRw== X-Gm-Message-State: AO0yUKVvzEeoI4ORDgIwSmkUJafvZp41aDJtML9GN2hMqFRpnhOuMHz1 dHaYGlLUOuAaEJqLjPtplEf4HC4inwH0S5rRlXFq7rMuMN7JWdZJ X-Google-Smtp-Source: AK7set9vXeSgnYo6TqPpoo/56Mw6FYIHUtwzdcHP37fx1ENgFZ6MBijzS3VKN/hLpEC9WX+JL12HZVO8thnpgBJuTnU= X-Received: by 2002:a05:6402:2811:b0:4af:70a5:5674 with SMTP id h17-20020a056402281100b004af70a55674mr2452149ede.0.1677340047021; Sat, 25 Feb 2023 07:47:27 -0800 (PST) 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 MIME-Version: 1.0 From: Warner Losh Date: Sat, 25 Feb 2023 08:47:17 -0700 Message-ID: Subject: Seeking feedback on CONTRIBUTING.md To: FreeBSD Current Content-Type: multipart/alternative; boundary="000000000000abaf2205f5882939" X-Spamd-Result: default: False [-3.00 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20210112.gappssmtp.com:s=20210112]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::52b:from]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; MIME_TRACE(0.00)[0:+,1:+,2:~]; R_SPF_NA(0.00)[no SPF record]; ARC_NA(0.00)[]; TO_DN_ALL(0.00)[]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; TO_MATCH_ENVRCPT_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; DKIM_TRACE(0.00)[bsdimp-com.20210112.gappssmtp.com:+]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; DMARC_NA(0.00)[bsdimp.com]; RCVD_COUNT_TWO(0.00)[2] X-Rspamd-Queue-Id: 4PPB3P4zNpz3J82 X-Spamd-Bar: -- X-ThisMailContainsUnwantedMimeParts: N --000000000000abaf2205f5882939 Content-Type: text/plain; charset="UTF-8" Greetings, I recently updated the contributing guidelines in the handbook to note the pull request experiment that I'm running on github. To that end, I've copied them into CONTRIBUTING.md and fleshed it out a bit with a couple of other resources. Please comment on my phabricator review: https://reviews.freebsd.org/D38771 Warner --000000000000abaf2205f5882939 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Greetings,

I recently update= d the contributing guidelines in the handbook to note the pull request expe= riment that I'm running on github.

To that end= , I've copied them into CONTRIBUTING.md and fleshed it out a bit with a= couple of other resources.

Please comment on my p= habricator review: https://r= eviews.freebsd.org/D38771

Warner
--000000000000abaf2205f5882939-- From nobody Sat Feb 25 16:16:25 2023 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 4PPBhs0w68z3tb2L; Sat, 25 Feb 2023 16:16:29 +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 "www.zefox.com", Issuer "www.zefox.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4PPBhq6vHYz3MTC; Sat, 25 Feb 2023 16:16:27 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Authentication-Results: mx1.freebsd.org; dkim=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; dmarc=none Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.17.1/8.15.2) with ESMTPS id 31PGGQPc011042 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Sat, 25 Feb 2023 08:16:26 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.17.1/8.15.2/Submit) id 31PGGQ4c011041; Sat, 25 Feb 2023 08:16:26 -0800 (PST) (envelope-from fbsd) Date: Sat, 25 Feb 2023 08:16:25 -0800 From: bob prohaska To: freebsd-arm@freebsd.org, freebsd-current@freebsd.org Subject: Re: Timekeeping problem in /usr/src on new RPI aarch64 snapshot Message-ID: <20230225161625.GB8127@www.zefox.net> References: <20230224210502.GA8127@www.zefox.net> <1216867532.11893.1677280869319@localhost> 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 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1216867532.11893.1677280869319@localhost> X-Spamd-Result: default: False [-1.10 / 15.00]; AUTH_NA(1.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.999]; MID_RHS_WWW(0.50)[]; WWW_DOT_DOMAIN(0.50)[]; MIME_GOOD(-0.10)[text/plain]; FROM_EQ_ENVFROM(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US]; R_SPF_NA(0.00)[no SPF record]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org,freebsd-current@freebsd.org]; RCPT_COUNT_TWO(0.00)[2]; ARC_NA(0.00)[]; TO_DN_NONE(0.00)[]; FROM_HAS_DN(0.00)[]; DMARC_NA(0.00)[zefox.net]; RCVD_COUNT_THREE(0.00)[3]; RCVD_TLS_LAST(0.00)[]; MID_RHS_MATCH_FROM(0.00)[] X-Rspamd-Queue-Id: 4PPBhq6vHYz3MTC X-Spamd-Bar: - X-ThisMailContainsUnwantedMimeParts: N On Sat, Feb 25, 2023 at 12:21:09AM +0100, Ronald Klop wrote: > > UFS stores the current timestamp in the superblock of the FS on clean > shutdown/unmount. On boot it reads the time from the timestamp in the > superblock of the root FS. Of coarse this timestamp is behind for the > duration that the machine was off or rebooting so you need to adjust that > using ntp. For ZFS root you can use the fakertc port to do something > similar. > > Mark Millard points out: /etc/localtime Current zoneinfo file, see tzsetup(8) and zic(8). /etc/wall_cmos_clock Empty file. Its presence indicates that the machine's CMOS clock is set to local time, while its absence indicates a UTC CMOS clock. Since there is no /etc/wall_cmos_clock on the newly-installed filesystem it appears the superblock timestamp is then interpreted as UTC when a Pi boots, using whatever happens to be set in /etc/localtime. My confusion is reduced somewhat. On first boot, what is the state of /etc/localtime? I've neglected to run tzsetup immediately on many previous installations and not noticed any complaints about mis-set clocks in buildworld. Is this new behavior? Thanks to both Mark and Ronald! bob prohaska From nobody Sat Feb 25 16:33:23 2023 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 4PPC4P4mRmz3tbgY; Sat, 25 Feb 2023 16:33:25 +0000 (UTC) (envelope-from mike@karels.net) Received: from mail2.karels.net (mail2.karels.net [3.19.118.201]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "freebsd", Issuer "freebsd" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4PPC4P4MWlz3hCb; Sat, 25 Feb 2023 16:33:25 +0000 (UTC) (envelope-from mike@karels.net) Authentication-Results: mx1.freebsd.org; none Received: from mail2.karels.net (localhost [IPv6:0:0:0:0:0:0:0:1]) by mail2.karels.net (8.16.1/8.16.1) with ESMTP id 31PGXOkY064695; Sat, 25 Feb 2023 10:33:24 -0600 (CST) (envelope-from mike@karels.net) Received: from [10.0.2.130] ([73.62.165.147]) by mail2.karels.net with ESMTPSA id Xg5THVQ4+mO1/AAAs/W3XQ (envelope-from ); Sat, 25 Feb 2023 10:33:24 -0600 From: Mike Karels To: bob prohaska Cc: freebsd-arm@freebsd.org, freebsd-current@freebsd.org Subject: Re: Timekeeping problem in /usr/src on new RPI aarch64 snapshot Date: Sat, 25 Feb 2023 10:33:23 -0600 X-Mailer: MailMate (1.14r5937) Message-ID: <0BA0C9F7-5F85-4EBF-86BB-428730746592@karels.net> In-Reply-To: <20230225161625.GB8127@www.zefox.net> References: <20230224210502.GA8127@www.zefox.net> <1216867532.11893.1677280869319@localhost> <20230225161625.GB8127@www.zefox.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 MIME-Version: 1.0 Content-Type: text/plain X-Rspamd-Queue-Id: 4PPC4P4MWlz3hCb X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:16509, ipnet:3.16.0.0/14, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N On 25 Feb 2023, at 10:16, bob prohaska wrote: > On Sat, Feb 25, 2023 at 12:21:09AM +0100, Ronald Klop wrote: >> >> UFS stores the current timestamp in the superblock of the FS on clean >> shutdown/unmount. On boot it reads the time from the timestamp in the >> superblock of the root FS. Of coarse this timestamp is behind for the >> duration that the machine was off or rebooting so you need to adjust that >> using ntp. For ZFS root you can use the fakertc port to do something >> similar. >> >> > Mark Millard points out: > /etc/localtime Current zoneinfo file, see tzsetup(8) and zic(8). > > /etc/wall_cmos_clock Empty file. Its presence indicates that the > machine's CMOS clock is set to local time, while > its absence indicates a UTC CMOS clock. > > Since there is no /etc/wall_cmos_clock on the newly-installed filesystem > it appears the superblock timestamp is then interpreted as UTC when a Pi > boots, using whatever happens to be set in /etc/localtime. My confusion > is reduced somewhat. On first boot, what is the state of /etc/localtime? > > I've neglected to run tzsetup immediately on many previous installations > and not noticed any complaints about mis-set clocks in buildworld. Is this > new behavior? /etc/localtime is used in formatting dates (e.g. for ls), but is not involved in storage of timestamps. Timestamps on files, system time, etc, are all in UTC. So the system should act normally if there is no /etc/localtime, and after one is added. Mike > Thanks to both Mark and Ronald! > > bob prohaska From nobody Sat Feb 25 17:02:38 2023 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 4PPCk90fb0z3tdYX; Sat, 25 Feb 2023 17:02:41 +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 "www.zefox.com", Issuer "www.zefox.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4PPCk85nzJz3lsx; Sat, 25 Feb 2023 17:02:40 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Authentication-Results: mx1.freebsd.org; none Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.17.1/8.15.2) with ESMTPS id 31PH2dXd011245 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Sat, 25 Feb 2023 09:02:39 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.17.1/8.15.2/Submit) id 31PH2ckB011244; Sat, 25 Feb 2023 09:02:38 -0800 (PST) (envelope-from fbsd) Date: Sat, 25 Feb 2023 09:02:38 -0800 From: bob prohaska To: Mike Karels Cc: freebsd-arm@freebsd.org, freebsd-current@freebsd.org Subject: Re: Timekeeping problem in /usr/src on new RPI aarch64 snapshot Message-ID: <20230225170238.GA11193@www.zefox.net> References: <20230224210502.GA8127@www.zefox.net> <1216867532.11893.1677280869319@localhost> <20230225161625.GB8127@www.zefox.net> <0BA0C9F7-5F85-4EBF-86BB-428730746592@karels.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 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0BA0C9F7-5F85-4EBF-86BB-428730746592@karels.net> X-Rspamd-Queue-Id: 4PPCk85nzJz3lsx X-Spamd-Bar: ---- 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-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N On Sat, Feb 25, 2023 at 10:33:23AM -0600, Mike Karels wrote: > On 25 Feb 2023, at 10:16, bob prohaska wrote: > > > On Sat, Feb 25, 2023 at 12:21:09AM +0100, Ronald Klop wrote: > >> > >> UFS stores the current timestamp in the superblock of the FS on clean > >> shutdown/unmount. On boot it reads the time from the timestamp in the > >> superblock of the root FS. Of coarse this timestamp is behind for the > >> duration that the machine was off or rebooting so you need to adjust that > >> using ntp. For ZFS root you can use the fakertc port to do something > >> similar. > >> > >> > > Mark Millard points out: > > /etc/localtime Current zoneinfo file, see tzsetup(8) and zic(8). > > > > /etc/wall_cmos_clock Empty file. Its presence indicates that the > > machine's CMOS clock is set to local time, while > > its absence indicates a UTC CMOS clock. > > > > Since there is no /etc/wall_cmos_clock on the newly-installed filesystem > > it appears the superblock timestamp is then interpreted as UTC when a Pi > > boots, using whatever happens to be set in /etc/localtime. My confusion > > is reduced somewhat. On first boot, what is the state of /etc/localtime? > > > > I've neglected to run tzsetup immediately on many previous installations > > and not noticed any complaints about mis-set clocks in buildworld. Is this > > new behavior? > > /etc/localtime is used in formatting dates (e.g. for ls), but is not > involved in storage of timestamps. Timestamps on files, system time, etc, > are all in UTC. So the system should act normally if there is no > /etc/localtime, and after one is added. Does formatting include calculating offsets from UTC for display? On at least a couple of installs I've observed date reporting UTC time. After running tzsetup, set to PST, date then reported the same numerical time with a PST time zone. This happened very early in an installation lifecycle and seemed to just "go away" after a few reboots, though I never paid close attention since it caused no complaints. Thanks for replying! bob prohaska