Обсуждение: ecpg-related build failure with make 3.82
On my Fedora 14 box, make -j3 fails. I think the below is the relevant portion of the output. This has a passing similarity to bug 5665, but I can't for the life of me see what the problem is here. parer.o depends on preproc.h, which depends on preproc.c; therefore, parser.o should not be built until preproc.c has been built, but that's exactly what make is doing. make[4]: Entering directory `/home/rhaas/pgsql/src/interfaces/ecpg/preproc' make -C ../../../../src/port all '/usr/bin/perl' ./parse.pl . < ../../../backend/parser/gram.y > preproc.y make[4]: Entering directory `/home/rhaas/pgsql/src/interfaces/ecpg/pgtypeslib' gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement -Wendif-labels -Wmissing-format-attribute -Wformat-security -fno-strict-aliasing -fwrapv -g -pthread -D_REENTRANT -D_THREAD_SAFE -D_POSIX_PTHREAD_SEMANTICS -fpic -I../include -I../../../../src/interfaces/ecpg/include -I../../../../src/include/utils -I../../../../src/interfaces/libpq -I../../../../src/include -D_GNU_SOURCE -DSO_MAJOR_VERSION=3 -c -o numeric.o numeric.c -MMD -MP -MF .deps/numeric.Po make[5]: Entering directory `/home/rhaas/pgsql/src/port' make -C ../backend submake-errcodes make[6]: Entering directory `/home/rhaas/pgsql/src/backend' make[6]: Nothing to be done for `submake-errcodes'. make[6]: Leaving directory `/home/rhaas/pgsql/src/backend' make[5]: Leaving directory `/home/rhaas/pgsql/src/port' /usr/bin/flex -o'pgc.c' pgc.l gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement -Wendif-labels -Wmissing-format-attribute -Wformat-security -fno-strict-aliasing -fwrapv -g -pthread -D_REENTRANT -D_THREAD_SAFE -D_POSIX_PTHREAD_SEMANTICS -DECPG_COMPILE -I../include -I../../../../src/interfaces/ecpg/include -I. -I. -DMAJOR_VERSION=4 -DMINOR_VERSION=7 -DPATCHLEVEL=0 -I../../../../src/include -D_GNU_SOURCE -c -o type.o type.c -MMD -MP -MF .deps/type.Po '/usr/bin/perl' ./check_rules.pl . ../../../backend/parser/gram.y gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement -Wendif-labels -Wmissing-format-attribute -Wformat-security -fno-strict-aliasing -fwrapv -g -pthread -D_REENTRANT -D_THREAD_SAFE -D_POSIX_PTHREAD_SEMANTICS -DECPG_COMPILE -I../include -I../../../../src/interfaces/ecpg/include -I. -I. -DMAJOR_VERSION=4 -DMINOR_VERSION=7 -DPATCHLEVEL=0 -I../../../../src/include -D_GNU_SOURCE -c -o ecpg.o ecpg.c -MMD -MP -MF .deps/ecpg.Po gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement -Wendif-labels -Wmissing-format-attribute -Wformat-security -fno-strict-aliasing -fwrapv -g -pthread -D_REENTRANT -D_THREAD_SAFE -D_POSIX_PTHREAD_SEMANTICS -DECPG_COMPILE -I../include -I../../../../src/interfaces/ecpg/include -I. -I. -DMAJOR_VERSION=4 -DMINOR_VERSION=7 -DPATCHLEVEL=0 -I../../../../src/include -D_GNU_SOURCE -c -o output.o output.c -MMD -MP -MF .deps/output.Po gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement -Wendif-labels -Wmissing-format-attribute -Wformat-security -fno-strict-aliasing -fwrapv -g -pthread -D_REENTRANT -D_THREAD_SAFE -D_POSIX_PTHREAD_SEMANTICS -fpic -I../include -I../../../../src/interfaces/ecpg/include -I../../../../src/include/utils -I../../../../src/interfaces/libpq -I../../../../src/include -D_GNU_SOURCE -DSO_MAJOR_VERSION=3 -c -o datetime.o datetime.c -MMD -MP -MF .deps/datetime.Po gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement -Wendif-labels -Wmissing-format-attribute -Wformat-security -fno-strict-aliasing -fwrapv -g -pthread -D_REENTRANT -D_THREAD_SAFE -D_POSIX_PTHREAD_SEMANTICS -DECPG_COMPILE -I../include -I../../../../src/interfaces/ecpg/include -I. -I. -DMAJOR_VERSION=4 -DMINOR_VERSION=7 -DPATCHLEVEL=0 -I../../../../src/include -D_GNU_SOURCE -c -o parser.o parser.c -MMD -MP -MF .deps/parser.Po gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement -Wendif-labels -Wmissing-format-attribute -Wformat-security -fno-strict-aliasing -fwrapv -g -pthread -D_REENTRANT -D_THREAD_SAFE -D_POSIX_PTHREAD_SEMANTICS -fpic -I../include -I../../../../src/interfaces/ecpg/include -I../../../../src/include/utils -I../../../../src/interfaces/libpq -I../../../../src/include -D_GNU_SOURCE -DSO_MAJOR_VERSION=3 -c -o common.o common.c -MMD -MP -MF .deps/common.Po parser.c:25:21: fatal error: preproc.h: No such file or directory compilation terminated. make[4]: *** [parser.o] Error 1 make[4]: Leaving directory `/home/rhaas/pgsql/src/interfaces/ecpg/preproc' make[3]: *** [all-preproc-recurse] Error 2 make[3]: *** Waiting for unfinished jobs.... -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
Robert Haas <robertmhaas@gmail.com> writes:
> On my Fedora 14 box, make -j3 fails. I think the below is the
> relevant portion of the output. This has a passing similarity to bug
> 5665, but I can't for the life of me see what the problem is here.
> parer.o depends on preproc.h, which depends on preproc.c; therefore,
> parser.o should not be built until preproc.c has been built, but
> that's exactly what make is doing.
I tried to reproduce this on my own Fedora 14 box, and couldn't.
I cd'd to src/interfaces/ecpg/preproc and did several repetitions of
make maintainer-cleanmake -j
and every time, make carefully waited until bison was done before
launching the compiles of preproc.o, parser.o, and the other files
that are declared to depend on preproc.h.
I *can* reproduce failures if I do the same thing one directory level
up, in src/interfaces/ecpg. But those are caused by the other sub-makes
not waiting for include/ecpg_config.h to get built. Fixing that is
beyond my level of make-fu.
This is with make-3.82-3.fc14.x86_64 ...
regards, tom lane
On Fri, Oct 28, 2011 at 1:24 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Robert Haas <robertmhaas@gmail.com> writes: >> On my Fedora 14 box, make -j3 fails. I think the below is the >> relevant portion of the output. This has a passing similarity to bug >> 5665, but I can't for the life of me see what the problem is here. >> parer.o depends on preproc.h, which depends on preproc.c; therefore, >> parser.o should not be built until preproc.c has been built, but >> that's exactly what make is doing. > > I tried to reproduce this on my own Fedora 14 box, and couldn't. > I cd'd to src/interfaces/ecpg/preproc and did several repetitions of > > make maintainer-clean > make -j > > and every time, make carefully waited until bison was done before > launching the compiles of preproc.o, parser.o, and the other files > that are declared to depend on preproc.h. I see the same thing. But when I do make -j3 at the toplevel, it bombs out as described before. > I *can* reproduce failures if I do the same thing one directory level > up, in src/interfaces/ecpg. But those are caused by the other sub-makes > not waiting for include/ecpg_config.h to get built. Fixing that is > beyond my level of make-fu. I can also reproduce this problem. I think this one does not occur on a fresh build because ecpg_config.h is created by configure and is only removed by make maintainer-clean. If I make maintainer-clean in src/interfaces/ecpg, then rerun config.status, and then do make -j it succeeds. However, if I repeat those steps from one level further up, in src/interfaces, then it bombs out as described in my OP. > This is with make-3.82-3.fc14.x86_64 ... That's the same make I'm using here. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
Robert Haas <robertmhaas@gmail.com> writes:
> On Fri, Oct 28, 2011 at 1:24 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> I tried to reproduce this on my own Fedora 14 box, and couldn't.
>> I cd'd to src/interfaces/ecpg/preproc and did several repetitions of
>>
>> make maintainer-clean
>> make -j
>>
>> and every time, make carefully waited until bison was done before
>> launching the compiles of preproc.o, parser.o, and the other files
>> that are declared to depend on preproc.h.
> I see the same thing. But when I do make -j3 at the toplevel, it
> bombs out as described before.
In that case it's a make bug, which you should file with the proper
authorities. I could believe it was our problem if it manifested when
starting from src/interfaces/ecpg, but none of the higher-level
makefiles know anything about subdirectories of ecpg.
>> I *can* reproduce failures if I do the same thing one directory level
>> up, in src/interfaces/ecpg. But those are caused by the other sub-makes
>> not waiting for include/ecpg_config.h to get built. Fixing that is
>> beyond my level of make-fu.
> I can also reproduce this problem. I think this one does not occur on
> a fresh build because ecpg_config.h is created by configure and is
> only removed by make maintainer-clean.
Well, on closer inspection, running ecpg/include/Makefile is sufficient
to rebuild ecpg_config.h, apparently because of rules in
Makefile.global. Now that I look at it, I bet we could fix that part
with some additions to the dependency rules in ecpg/Makefile. But it
doesn't seem related at all to the preproc problem.
regards, tom lane
Hi. I tested that make 3.82 - win32 version hasn't any new functionalities for example .ONESHELL. -- ------------ pasman