OS X 7.4 failure

"Jim C. Nasby" <jnasby@pervasive.com> writes:

So the recent thread about getting 7.4 compiling on OS X inspired me.
But what I can't understand is that I've yanked --with-ssl, but it's
still looking for libssl:

Tad hard to believe. Maybe you missed a "make distclean" or so?
(BTW, the flag is --with-openssl ... --with-ssl would do nothing :-()

regards, tom lane

On Tue, Nov 15, 2005 at 11:04:59PM -0500, Tom Lane wrote:

"Jim C. Nasby" <jnasby@pervasive.com> writes:

So the recent thread about getting 7.4 compiling on OS X inspired me.
But what I can't understand is that I've yanked --with-ssl, but it's
still looking for libssl:

Tad hard to believe. Maybe you missed a "make distclean" or so?

buildfar@phonebook.1[22:22]~/buildfarm/REL7_4_STABLE/pgsql:21%make
distclean
You need to run the 'configure' program first. See the file
'INSTALL' for installation instructions.
make: *** [distclean] Error 1
buildfar@phonebook.1[22:22]~/buildfarm/REL7_4_STABLE/pgsql:22%

I'll try nuking the checkout anyway...

(BTW, the flag is --with-openssl ... --with-ssl would do nothing :-()

Yeah, sorry, was going from my (faulty) memory.
--
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

On Tue, Nov 15, 2005 at 11:04:59PM -0500, Tom Lane wrote:

"Jim C. Nasby" <jnasby@pervasive.com> writes:

So the recent thread about getting 7.4 compiling on OS X inspired me.
But what I can't understand is that I've yanked --with-ssl, but it's
still looking for libssl:

Tad hard to believe. Maybe you missed a "make distclean" or so?
(BTW, the flag is --with-openssl ... --with-ssl would do nothing :-()

Hrm, I am using ccache... maybe it's got a screw loose. I'll try wiping
the cache next if the clean checkout doesn't do it.
--
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

Tom Lane wrote:

"Jim C. Nasby" <jnasby@pervasive.com> writes:

So the recent thread about getting 7.4 compiling on OS X inspired me.
But what I can't understand is that I've yanked --with-ssl, but it's
still looking for libssl:

Tad hard to believe. Maybe you missed a "make distclean" or so?

"make distclean" should never be necessary for a buildfarm run - we
always build in one of these 3 ways:

. against a fresh checkout made with 'cvs export'
. against a one-off temporary copy of our local repo, made after we ran
cvs update
. against our local repo using VPATH

The recent release of buildfarm code goes to some length to ensure that
the repo is clean, in case somebody has mangled it by hand.

cheers

andrew

Andrew Dunstan <andrew@dunslane.net> writes:

Tom Lane wrote:

"Jim C. Nasby" <jnasby@pervasive.com> writes:

So the recent thread about getting 7.4 compiling on OS X inspired me.
But what I can't understand is that I've yanked --with-ssl, but it's
still looking for libssl:

Tad hard to believe. Maybe you missed a "make distclean" or so?

"make distclean" should never be necessary for a buildfarm run - we
always build in one of these 3 ways:

He didn't say it was a buildfarm run.

regards, tom lane

Tom Lane wrote:

Andrew Dunstan <andrew@dunslane.net> writes:

Tom Lane wrote:

"Jim C. Nasby" <jnasby@pervasive.com> writes:

So the recent thread about getting 7.4 compiling on OS X inspired me.
But what I can't understand is that I've yanked --with-ssl, but it's
still looking for libssl:

Tad hard to believe. Maybe you missed a "make distclean" or so?

"make distclean" should never be necessary for a buildfarm run - we
always build in one of these 3 ways:

He didn't say it was a buildfarm run.

Yeah he did ;-) He said:

But what I can't understand is that I've yanked --with-ssl, but it's
still looking for libssl:
http://pgbuildfarm.org/cgi-bin/show_log.pl?nm=cuckoo&amp;dt=2005-11-15%2023:56:22

anyway, no biggie.

cheers

andrew

On Tue, Nov 15, 2005 at 10:27:06PM -0600, Jim C. Nasby wrote:

On Tue, Nov 15, 2005 at 11:04:59PM -0500, Tom Lane wrote:

"Jim C. Nasby" <jnasby@pervasive.com> writes:

So the recent thread about getting 7.4 compiling on OS X inspired me.
But what I can't understand is that I've yanked --with-ssl, but it's
still looking for libssl:

Tad hard to believe. Maybe you missed a "make distclean" or so?
(BTW, the flag is --with-openssl ... --with-ssl would do nothing :-()

Hrm, I am using ccache... maybe it's got a screw loose. I'll try wiping
the cache next if the clean checkout doesn't do it.

Well, I've tried blowing away the CVS checkout
(http://lnk.nu/pgbuildfarm.org/62o.pl) and clearing out my ccache
(http://lnk.nu/pgbuildfarm.org/62p.pl), but I'm still getting the same
failure. I do have perl, python, tcl and nls enabled, could one of them
be trying to pull libssl and libcrypto in for some reason?
--
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

"Jim C. Nasby" <jnasby@pervasive.com> writes:

I do have perl, python, tcl and nls enabled, could one of them
be trying to pull libssl and libcrypto in for some reason?

Perhaps --- try "otool -L" (local equivalent of ldd) on them to find
out.

regards, tom lane

On Wed, Nov 16, 2005 at 11:50:51AM -0500, Tom Lane wrote:

"Jim C. Nasby" <jnasby@pervasive.com> writes:

I do have perl, python, tcl and nls enabled, could one of them
be trying to pull libssl and libcrypto in for some reason?

Perhaps --- try "otool -L" (local equivalent of ldd) on them to find
out.

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)
buildfar@phonebook.1[11:13]~/buildfarm/source:40%otool -L `which python`
/opt/local/bin/python:
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 71.1.1)
buildfar@phonebook.1[11:13]~/buildfarm/source:41%otool -L `which tclsh`
/opt/local/bin/tclsh:
/opt/local/lib/libtcl8.4.dylib (compatibility version 8.4.0, current version 8.4.11)
/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 299.35.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 71.1.3)
buildfar@phonebook.1[11:14]~/buildfarm/source:42%otool -L /opt/local/lib/libtcl8.4.dylib
/opt/local/lib/libtcl8.4.dylib:
/opt/local/lib/libtcl8.4.dylib (compatibility version 8.4.0, current version 8.4.11)
/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 299.35.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 71.1.3)
buildfar@phonebook.1[11:14]~/buildfarm/source:43%

I'll try yanking that stuff in any case...
--
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

"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

"Jim C. Nasby" <jnasby@pervasive.com> writes:

http://pgbuildfarm.org/cgi-bin/show_log.pl?nm=cuckoo&amp;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

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&amp;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:
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