Thread: Re: BUG #17178: probes.h: No such file or directory when running 'make install'
Re: BUG #17178: probes.h: No such file or directory when running 'make install'
From
Kevin Burke
Date:
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.
On Thu, Sep 2, 2021 at 9:57 PM PG Bug reporting form <noreply@postgresql.org> wrote:
The following bug has been logged on the website:
Bug reference: 17178
Logged by: Kevin Burke
Email address: kevin@meter.com
PostgreSQL version: 14beta3
Operating system: MacOS Catalina 10.15.7
Description:
I am compiling Postgres from commit c95ede41b8d47b21d58702fbc519e720f41fdaf1
on master. I am running "gmake clean && ./configure --prefix=$HOME/pq &&
gmake && gmake install" (gmake being GNU make). I receive the following
error on either the "gmake install" or "gmake check" steps:
/Users/kevin/local/coreutils/bin/install -c -m 644 utils/fmgrprotos.h
'/Users/kevin/pq/include/postgresql/server/utils'
cp ./*.h '/Users/kevin/pq/include/postgresql/server'/
for dir in access bootstrap catalog commands common datatype executor
fe_utils foreign jit lib libpq mb nodes optimizer parser partitioning
postmaster regex replication rewrite statistics storage tcop snowball
snowball/libstemmer tsearch tsearch/dicts utils port port/atomics port/win32
port/win32_msvc port/win32_msvc/sys port/win32/arpa port/win32/netinet
port/win32/sys portability; do \
cp ./$dir/*.h '/Users/kevin/pq/include/postgresql/server'/$dir/ || exit;
\
done
cp: '../../../src/backend/utils/probes.h' ->
'/Users/kevin/pq/include/postgresql/server/utils/probes.h': No such file or
directory (os error 2)
gmake[2]: *** [Makefile:49: install] Error 1
gmake[2]: Leaving directory
'/Users/kevin/src/github.com/postgres/postgres/src/include'
gmake[1]: *** [Makefile:42: install-include-recurse] Error 2
gmake[1]: Leaving directory
'/Users/kevin/src/github.com/postgres/postgres/src'
gmake: *** [GNUmakefile:11: install-src-recurse] Error 2
Here are the copies of files named "probes.h" on my local filesystem, from
the git root:
$ find . -name probes.h
./local/include/server/utils/probes.h
./src/include/utils/probes.h
./src/backend/utils/probes.h
There are lots of .h files in
/Users/kevin/pq/include/postgresql/server/utils but probes.h is not one of
them.
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):
$ 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
Re: BUG #17178: probes.h: No such file or directory when running 'make install'
From
Kevin Burke
Date:
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.
On Fri, Sep 3, 2021 at 06:23 Tom Lane <tgl@sss.pgh.pa.us> wrote:
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):
$ 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