Heikki Linnakangas wrote: > Also, I'm seeing a failure in buildfarm member 'colugos': > > /opt/local/bin/ccache /Developer/usr/bin/llvm-gcc-4.2 -no-cpp-precomp > -I/opt/local/include -Wall -Wmissing-prototypes -Wpointer-arith > -Wdeclaration-after-statement -Wendif-labels -fno-strict-aliasing > -fwrapv -g -bundle -multiply_defined suppress walreceiver.o > -bundle_loader ../../../../src/backend/postgres > -L../../../../src/interfaces/libpq -L../../../../src/port > -L/opt/local/lib -lpq -o walreceiver.so > ld: library not found for -lpq > collect2: ld returned 1 exit status > make[2]: *** [walreceiver.so] Error 1 > make[2]: *** Waiting for unfinished jobs.... > > I suspect that's because libpq isn't built yet. I have this: > >> all: submake-libpq all-shared-lib > > in src/backend/replication/walreceiver/Makefile, but is that not enough?
Yep. What's happening is that "make -j" starts building libpq and walreceiver.so simultaneously, because of the above line in the Makefile. We actually have the same problem in src/bin/*/Makefile, but we don't notice it there because src/interfaces is listed before src/bin in src/Makefile, so when you do "make -j" at the top-level, libpq is built first. You get the same error if you do "make clean" at the top-level, and then e.g "cd src/bin/scripts/; make -j" So the simple fix would be to reorder the lines in src/Makefile, so that src/interfaces is built before src/backend. Alternatively we could do this: *** src/backend/replication/walreceiver/Makefile 15 Jan 2010 09:19:03 -0000 1.1 --- src/backend/replication/walreceiver/Makefile 15 Jan 2010 13:57:24 -0000 *************** *** 18,24 **** SHLIB_LINK = $(libpq) NAME = walreceiver ! all: submake-libpq all-shared-lib include $(top_srcdir)/src/Makefile.shlib --- 18,28 ---- SHLIB_LINK = $(libpq) NAME = walreceiver ! all: all-shared-lib ! ! # Compiling walreceiver.o doesn't really need libpq library, ! # only linking it does. But there's no easy way to specify that. ! walreceiver.o: submake-libpq include $(top_srcdir)/src/Makefile.shlib And I guess all the other uses of submake-libpq should be changed similarly. Am I missing a trick? -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers