Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mM9AV-0002we-Vb for pgsql-bugs@arkaria.postgresql.org; Fri, 03 Sep 2021 13:23:43 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1mM9AU-0001v4-S4 for pgsql-bugs@arkaria.postgresql.org; Fri, 03 Sep 2021 13:23:42 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mM9AU-0001uw-LN for pgsql-bugs@lists.postgresql.org; Fri, 03 Sep 2021 13:23:42 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mM9AS-0003Ou-46 for pgsql-bugs@lists.postgresql.org; Fri, 03 Sep 2021 13:23:41 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 183DNdFw2481302; Fri, 3 Sep 2021 09:23:39 -0400 From: Tom Lane To: Kevin Burke cc: pgsql-bugs@lists.postgresql.org Subject: Re: BUG #17178: probes.h: No such file or directory when running 'make install' In-reply-to: References: <17178-daf8e5afdcd926a0@postgresql.org> Comments: In-reply-to Kevin Burke message dated "Thu, 02 Sep 2021 22:01:32 -0700" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <2481300.1630675418.1@sss.pgh.pa.us> Content-Transfer-Encoding: quoted-printable Date: Fri, 03 Sep 2021 09:23:39 -0400 Message-ID: <2481301.1630675419@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Kevin Burke writes: > Aha, never mind... I am using the Rust "coreutils" and this appears to b= e > an incompatibility between the GNU "cp" tool and the Rust cp tool. While > concerning I don't think that this is Postgres's fault. It looks more like gmake having dropped the ball somewhere along the line --- probes.h is a built file, plus it's symlinked in various places. We know that Apple's /usr/bin/make works, but maybe you're using something different? Also, it could matter whether this is a VPATH build or not. FWIW, this is what I see immediately after a clean build on my Big Sur laptop (non-VPATH): $ find . -name probes.h | xargs ls -ld -rw-r--r-- 1 tgl admin 7568 Sep 3 09:16 ./src/backend/utils/probes.h lrwxr-xr-x 1 tgl admin 35 Sep 3 09:16 ./src/include/utils/probes.h -= > ../../../src/backend/utils/probes.h Looking at the install rule in src/include/Makefile, it looks like it first blindly installs the symlink along with everything else in src/include/utils, and then overwrites that with the non-symlink copy. So I guess if you have a version of "cp" with non-POSIX rules for what to do with symlinks, this could indeed be "cp"'s fault ... but that would be a cp bug, and a rather big one. regards, tom lane