"Jim C. Nasby" <jnasby@pervasive.com> writes:
> buildfar@phonebook.1[11:13]~/buildfarm/source:39%otool -L `which perl`
> /opt/local/bin/perl:
> /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 71.1.3)

These aren't particularly relevant: you need to look at the shared
libraries that are being pulled into the PG link commands, not random
standalone executables that happen to come from the same package.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

"Jim C. Nasby" <jnasby@pervasive.com> writes:
> http://pgbuildfarm.org/cgi-bin/show_...-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

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_...-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:
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 (compatibility version 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 (compatibility version 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

---------------------------(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