"Jim C. Nasby" <jnasby@pervasive.com> writes:
> http://pgbuildfarm.org/cgi-bin/show_log.pl?nm=cuckoo&dt=2005-11-15%2023:56:22
I took a closer look at this, and noticed something interesting:
ccache gcc -no-cpp-precomp -O2 -fno-strict-aliasing -g -Wall -Wmissing-prototypes -Wmissing-declarations -bundle
execute.otypename.o descriptor.o data.o error.o prepare.o memory.o connect.o misc.o path.o -L../pgtypeslib
-L../../../../src/interfaces/libpq-L../../../../src/port -L/opt/local/lib -lpgtypes -lpq -lintl -lm -o libecpg.so.4.1
ld: warning can't open dynamic library: /opt/local/lib/libssl.0.9.7.dylib (checking for undefined symbols may be
affected)(No such file or directory, errno = 2)
ld: warning can't open dynamic library: /opt/local/lib/libcrypto.0.9.7.dylib (checking for undefined symbols may be
affected)(No such file or directory, errno = 2)
ld: warning multiple definitions of symbol _pg_strncasecmp
/opt/local/lib/libpgtypes.dylib(pgstrcasecmp.o) definition of _pg_strncasecmp
/opt/local/lib/libpq.dylib(pgstrcasecmp.o) definition of _pg_strncasecmp
You should be asking yourself "what the heck is it doing pulling in
libpgtypes and libpq from /opt/local/lib instead of the current build?
That's way down the -L search list."
I am not sure about Darwin's linker search rules, but it could easy be
that it first looks through the entire search path for a .dylib and only
upon failing looks for a .so. If so, a .dylib lurking in /opt/local/lib
could capture the build away from the .so that the 7.4 build process
tries to make.
Solution would be to remove the PG libraries from /opt/local/lib, or
else remove /opt/local/lib from the search path for the 7.4 build
(which'd probably mean removing --with-tcl etc, but I'm not sure they
would work anyway).
regards, tom lane
