parallel make failure

Andrew Dunstan <andrew@dunslane.net> writes:

We still seem to have some dependency issues with parallel builds. I
just got this on a fresh F16 box against git tip, when running "make -j 3":

ccache 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 -I/usr/include/libxml2 -c -o parser.o parser.c -MMD
-MP -MF .deps/parser.Po
parser.c:25:21: fatal error: preproc.h: No such file or directory
compilation terminated.

I think you have a broken version of "make". ecpg/preproc/Makefile
is perfectly clear that parser.o depends on preproc.h.

regards, tom lane

On 11/09/2011 11:35 AM, Tom Lane wrote:

Andrew Dunstan<andrew@dunslane.net> writes:

We still seem to have some dependency issues with parallel builds. I
just got this on a fresh F16 box against git tip, when running "make -j 3":
ccache 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 -I/usr/include/libxml2 -c -o parser.o parser.c -MMD
-MP -MF .deps/parser.Po
parser.c:25:21: fatal error: preproc.h: No such file or directory
compilation terminated.

I think you have a broken version of "make". ecpg/preproc/Makefile
is perfectly clear that parser.o depends on preproc.h.

Stock distro build:

GNU Make 3.82
Built for i386-redhat-linux-gnu

It's not repeatable, at least not easily.

I'll let it go, but I won't be surprised if we see sporadic reports of this.

cheers

andrew

On Wed, Nov 9, 2011 at 11:46 AM, Andrew Dunstan <andrew@dunslane.net> wrote:

On 11/09/2011 11:35 AM, Tom Lane wrote:

Andrew Dunstan<andrew@dunslane.net>  writes:

We still seem to have some dependency issues with parallel builds. I
just got this on a fresh F16 box against git tip, when running "make -j
3":
    ccache 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 -I/usr/include/libxml2   -c -o parser.o parser.c -MMD
    -MP -MF .deps/parser.Po
    parser.c:25:21: fatal error: preproc.h: No such file or directory
    compilation terminated.

I think you have a broken version of "make".  ecpg/preproc/Makefile
is perfectly clear that parser.o depends on preproc.h.

Stock distro build:

  GNU Make 3.82
  Built for i386-redhat-linux-gnu

It's not repeatable, at least not easily.

I'll let it go, but I won't be surprised if we see sporadic reports of this.

Either make 3.82 is broken, or there's something about it's behavior
we don't understand. We've had other reports of problems with that
version (by me, just a week or two ago, at least).

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

Robert Haas <robertmhaas@gmail.com> writes:

On 11/09/2011 11:35 AM, Tom Lane wrote:

I think you have a broken version of "make". ecpg/preproc/Makefile
is perfectly clear that parser.o depends on preproc.h.

Either make 3.82 is broken, or there's something about it's behavior
we don't understand. We've had other reports of problems with that
version (by me, just a week or two ago, at least).

I wonder whether it's related to the dummy rule for preproc.h:

preproc.h: preproc.c ;

preproc.c: preproc.y
ifdef BISON
$(BISON) -d $(BISONFLAGS) -o $@ $<
else
@$(missing) bison $< $@
endif

I'd be tempted to try a non-empty rule for that, perhaps

preproc.h: preproc.c
@echo "preproc.c rebuilt"

and see if that makes any difference.

BTW, didn't we establish that it makes a difference whether you launch
the make run from the top level or locally in ecpg/preproc/? That seems
to me to be prima facie evidence of a make bug.

regards, tom lane