"Jim C. Nasby" <[EMAIL PROTECTED]> 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.o typename.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
---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
