Thread: OS X 7.4 failure
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: http://pgbuildfarm.org/cgi-bin/show_log.pl?nm=cuckoo&dt=2005-11-15%2023:56:22 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: Undefined symbols: _SSL_pending referenced from libpq expected to be defined in /opt/local/lib/libssl.0.9.7.dylib _BIO_free referenced from libpq expected to be defined in /opt/local/lib/libcrypto.0.9.7.dylib ... Am I missing something else? The only things I see in configure that call for libcrypto are SSL and KRB, neither of which are configured... -- 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:
> 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&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 version299.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&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). 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&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