That looks the same as my machine - I also have a symlink there. Here is the ticket - coreutils cp is currently broken if the working directory is not the same as the one with a symlink.
Kevin Burke <kevin@meter.com> writes: > Aha, never mind... I am using the Rust "coreutils" and this appears to be > 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):
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.
