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