Обсуждение: 'make check' fails
I have discovered that:
make clean; make check
fails with:
/bin/mkdir -p '/pgtop'/tmp_install/log
make -C '.' DESTDIR='/pgtop'/tmp_install install >'/pgtop'/tmp_install/log/install.log 2>&1
src/Makefile.global:388: recipe for target 'temp-install' failed
make: *** [temp-install] Error 2
and '/pgtop'/tmp_install/log/install.log says:
relpath.c:21:37: fatal error: catalog/pg_tablespace_d.h: No such file or directory
#include "catalog/pg_tablespace_d.h"
^
compilation terminated.
<builtin>: recipe for target 'relpath.o' failed
make[3]: *** [relpath.o] Error 1
Oddly, this works:
make clean; make; make check
I found this because I have some scripts that do the former. The
problem has existed for several days now and I only now dug into it.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
Bruce Momjian <bruce@momjian.us> writes:
> I have discovered that:
> make clean; make check
> fails with:
No doubt this is related to the generated-headers changes I've been
making, but I find your recipe confusing. "make clean" should not
have removed the generated headers from the previous build. I can
believe that if you started from a bare git checkout, did configure
and then immediately "make check", that would fail ... but I don't
think that worked before either. If it did it was certainly subject
to parallel-make race conditions.
Please be more explicit about what state you're starting from.
regards, tom lane
On Wed, Apr 11, 2018 at 10:59:45AM -0400, Tom Lane wrote:
> Bruce Momjian <bruce@momjian.us> writes:
> > I have discovered that:
> > make clean; make check
> > fails with:
>
> No doubt this is related to the generated-headers changes I've been
> making, but I find your recipe confusing. "make clean" should not
> have removed the generated headers from the previous build. I can
> believe that if you started from a bare git checkout, did configure
> and then immediately "make check", that would fail ... but I don't
> think that worked before either. If it did it was certainly subject
> to parallel-make race conditions.
>
> Please be more explicit about what state you're starting from.
OK, I can reproduce it with this:
make distclean; configure; make clean check
This is not supposed to work? It should be this?
make distclean; configure; make clean; make; make check
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
>>>>> "Tom" == Tom Lane <tgl@sss.pgh.pa.us> writes:
Tom> No doubt this is related to the generated-headers changes I've
Tom> been making, but I find your recipe confusing. "make clean" should
Tom> not have removed the generated headers from the previous build. I
Tom> can believe that if you started from a bare git checkout, did
Tom> configure and then immediately "make check", that would fail ...
Tom> but I don't think that worked before either. If it did it was
Tom> certainly subject to parallel-make race conditions.
Tom> Please be more explicit about what state you're starting from.
This is consistently failing for me, on FreeBSD with GNU Make 4.2.1,
clang 3.9.1, at commit 651cb90941:
git clean -dfx
./configure '--prefix=/home/andrew/work/pgsql/head' \
'--with-includes=/usr/local/include' '--with-libs=/usr/local/lib' \
'--enable-debug' '--enable-depend' 'CFLAGS=-O0' '--enable-cassert' \
gmake -j4
gmake clean
gmake -j4 check
install.log shows:
relpath.c:21:10: fatal error: 'catalog/pg_tablespace_d.h' file not found
#include "catalog/pg_tablespace_d.h"
^
1 error generated.
--
Andrew (irc:RhodiumToad)
Andrew Gierth <andrew@tao11.riddles.org.uk> writes:
> Tom> Please be more explicit about what state you're starting from.
> This is consistently failing for me, on FreeBSD with GNU Make 4.2.1,
> clang 3.9.1, at commit 651cb90941:
> git clean -dfx
> ./configure '--prefix=/home/andrew/work/pgsql/head' \
> '--with-includes=/usr/local/include' '--with-libs=/usr/local/lib' \
> '--enable-debug' '--enable-depend' 'CFLAGS=-O0' '--enable-cassert' \
> gmake -j4
> gmake clean
> gmake -j4 check
Oh ... I forgot that "make clean" removes the symlinks in
src/include/catalog. Still, that also removes
src/include/utils/errcodes.h, so there was a parallel-make hazard
here before too.
We can fix this by making submake-generated-headers be a recursive
prerequisite for "check" as well as "all" and "install". I wonder
whether anybody is expecting any other shortcuts to work.
regards, tom lane
Tom Lane wrote: > We can fix this by making submake-generated-headers be a recursive > prerequisite for "check" as well as "all" and "install". I wonder > whether anybody is expecting any other shortcuts to work. check-world certainly, but presumably that depends on check? -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On Wed, Apr 11, 2018 at 12:35:41PM -0400, Tom Lane wrote: > Andrew Gierth <andrew@tao11.riddles.org.uk> writes: > > Tom> Please be more explicit about what state you're starting from. > > > This is consistently failing for me, on FreeBSD with GNU Make 4.2.1, > > clang 3.9.1, at commit 651cb90941: > > > git clean -dfx > > ./configure '--prefix=/home/andrew/work/pgsql/head' \ > > '--with-includes=/usr/local/include' '--with-libs=/usr/local/lib' \ > > '--enable-debug' '--enable-depend' 'CFLAGS=-O0' '--enable-cassert' \ > > gmake -j4 > > gmake clean > > gmake -j4 check > > Oh ... I forgot that "make clean" removes the symlinks in > src/include/catalog. Still, that also removes > src/include/utils/errcodes.h, so there was a parallel-make hazard > here before too. > > We can fix this by making submake-generated-headers be a recursive > prerequisite for "check" as well as "all" and "install". I wonder > whether anybody is expecting any other shortcuts to work. In case it wasn't clear, I can reproduce this failure without parallel mode. FYI, the reason I used this shortcut is so I can just run one command and check one error code to know if they all worked; see src/tools/pgtest for an example. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription +
Alvaro Herrera <alvherre@alvh.no-ip.org> writes:
> Tom Lane wrote:
>> We can fix this by making submake-generated-headers be a recursive
>> prerequisite for "check" as well as "all" and "install". I wonder
>> whether anybody is expecting any other shortcuts to work.
> check-world certainly, but presumably that depends on check?
world is OK because that already depends on "all" at the top level.
(The reason "check" is failing is basically that the "check: all"
dependencies only appear below the top level, and the MAKELEVEL
hack prevents submake-generated-headers from doing anything in
recursive child makes.)
regards, tom lane
Bruce Momjian <bruce@momjian.us> writes:
> On Wed, Apr 11, 2018 at 12:35:41PM -0400, Tom Lane wrote:
>> We can fix this by making submake-generated-headers be a recursive
>> prerequisite for "check" as well as "all" and "install". I wonder
>> whether anybody is expecting any other shortcuts to work.
> In case it wasn't clear, I can reproduce this failure without parallel
> mode. FYI, the reason I used this shortcut is so I can just run one
> command and check one error code to know if they all worked; see
> src/tools/pgtest for an example.
Probably, you got out of the habit of using parallel mode because it
fell over from time to time. The way things were done before, there
were race conditions in this usage, due to different subdirectories
independently trying to update the same generated headers.
Will commit a fix in a bit.
regards, tom lane
On Wed, Apr 11, 2018 at 01:04:56PM -0400, Tom Lane wrote: > Bruce Momjian <bruce@momjian.us> writes: > > On Wed, Apr 11, 2018 at 12:35:41PM -0400, Tom Lane wrote: > >> We can fix this by making submake-generated-headers be a recursive > >> prerequisite for "check" as well as "all" and "install". I wonder > >> whether anybody is expecting any other shortcuts to work. > > > In case it wasn't clear, I can reproduce this failure without parallel > > mode. FYI, the reason I used this shortcut is so I can just run one > > command and check one error code to know if they all worked; see > > src/tools/pgtest for an example. > > Probably, you got out of the habit of using parallel mode because it > fell over from time to time. The way things were done before, there > independently trying to update the same generated headers. I do use parallel make but was testing without it just in case. > Will commit a fix in a bit. I can confirm the fix. Thanks. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription +