On Thu, Nov 17, 2005 at 12:51:47AM -0500, Tom Lane wrote:
> "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).
Excellent catch, it seems that could be what's happening:
[EMAIL PROTECTED]:28]~:5%otool -L /opt/local/lib/libpq.dylib
/opt/local/lib/libpq.dylib:
/opt/local/lib/libpq.4.dylib (compatibility version 4.0.0, current
version 4.0.0)
/opt/local/lib/libssl.0.9.7.dylib (compatibility version 0.9.0, current
version 0.9.7)
/opt/local/lib/libcrypto.0.9.7.dylib (compatibility version 0.9.0,
current version 0.9.7)
/usr/lib/libresolv.9.dylib (compatibility version 1.0.0, current
version 324.9.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
version 71.1.3)
[EMAIL PROTECTED]:29]~:6%ll /opt/local/lib/libssl.*
-r-xr-xr-x 2 root admin 322596 22 Jul 02:12
/opt/local/lib/libssl.0.9.8.dylib*
-rw-r--r-- 2 root admin 468100 22 Jul 02:12 /opt/local/lib/libssl.a
-r-xr-xr-x 2 root admin 322596 22 Jul 02:12 /opt/local/lib/libssl.dylib*
[EMAIL PROTECTED]:30]~:7%
What's interesting (at least to me) is that psql still works fine, even though
it's calling for a version of sibssl that doesn't exist on my laptop:
[EMAIL PROTECTED]:30]~:7%otool -L `which psql`
/opt/local/bin/psql:
/opt/local/lib/libpq.4.dylib (compatibility version 4.0.0, current
version 4.0.0)
/opt/local/lib/libssl.0.9.7.dylib (compatibility version 0.9.0, current
version 0.9.7)
/opt/local/lib/libcrypto.0.9.7.dylib (compatibility version 0.9.0,
current version 0.9.7)
/opt/local/lib/libz.1.dylib (compatibility version 1.0.0, current
version 1.2.2)
/opt/local/lib/libreadline.5.0.dylib (compatibility version 5.0.0,
current version 5.0.0)
/usr/lib/libresolv.9.dylib (compatibility version 1.0.0, current
version 324.9.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
version 71.1.3)
[EMAIL PROTECTED]:31]~:8%
Do you happen to know how Apple's linker gets it's search path? There doesn't
seem to be ldconfig or ldconf, and the few things in my environment that
reference /opt seem innocent. I can obviously fix the library issue by
re-compiling the main PostgreSQL install on this box, but ISTM it would be best
if the buildfarm stuff was as seperated from that as possible...
--
Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED]
Pervasive Software http://pervasive.com work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
