Re: OS X 7.4 failure - Mailing list pgsql-hackers

On Thu, Nov 17, 2005 at 12:51:47AM -0500, Tom Lane wrote:
> "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).

Excellent catch, it seems that could be what's happening:
buildfar@phonebook.1[13: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
(compatibilityversion 1.0.0, current version 71.1.3)
 
buildfar@phonebook.1[13: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*
buildfar@phonebook.1[13: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:

buildfar@phonebook.1[13: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
(compatibilityversion 1.0.0, current version 71.1.3)
 
buildfar@phonebook.1[13: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      jnasby@pervasive.com
Pervasive Software      http://pervasive.com    work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf       cell: 512-569-9461