Andrew Dunstan <and...@dunslane.net> writes: > I have just repeated this on an absolutely fresh up to date F17 machine, > with no symlink stuff in play.
> Steps to recreate: > CC="ccache gcc" ../postgres/configure --enable-depend --enable-debug > --enable-cassert --with-perl --with-python --with-tcl --with-libxml > --with-libxslt -with-openssl --with-gssapi --with-pam --with-ldap > make -j 4 Huh ... that recipe works (er, fails) for me too, at least some of the time. I wonder what exactly is the key difference between the working and failing cases? Anyway, what I notice is that I get different types of failures, but they are all under ecpg/. What I think we need to do is insert .NOTPARALLEL in ecpg/Makefile, because there are several reasons not to run its sub-makes in parallel: * preproc/Makefile casually does this: ../ecpglib/typename.o: ../ecpglib/typename.c $(MAKE) -C $(dir $@) $(notdir $@) which is very likely to screw up any make proceeding in parallel in ecpglib. * compatlib and ecpglib will equally casually invoke "make all" in other subdirectories; ditto. And that's not even counting the bison-output problem you were seeing. I'm not entirely sure what's causing that, but I'm suspicious that the ultimate cause is the extra rules for the "all...recurse" targets in ecpg/Makefile, which look like they could result in additional instances of multiple make processes running in the same subdirectory. After adding the .NOTPARALLEL marker, I don't see these failures anymore. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers