Re: 64-bit Compile Failure on Solaris 10 with OpenSSL - Mailing list pgsql-general

From Randal T. Rioux
Subject Re: 64-bit Compile Failure on Solaris 10 with OpenSSL
Date
Msg-id 2b22e7c8403a5082eb04a3541514b569.squirrel@meteor.procyonlabs.com
Whole thread Raw
In response to 64-bit Compile Failure on Solaris 10 with OpenSSL  ("Randal T. Rioux" <randy@procyonlabs.com>)
Responses Re: 64-bit Compile Failure on Solaris 10 with OpenSSL  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: 64-bit Compile Failure on Solaris 10 with OpenSSL  (Greg Smith <gsmith@gregsmith.com>)
List pgsql-general
On Sat, September 6, 2008 8:21 pm, Tom Lane wrote:
> "Randal T. Rioux" <randy@procyonlabs.com> writes:
>> On Sat, September 6, 2008 7:05 pm, Tom Lane wrote:
>>> configure:19857: $? = 0 configure:19859: ./conftest ld.so.1:
>>> conftest: fatal: libgcc_s.so.1: open failed: No such file or
>>> directory ./configure: line 19860: 20583 Killed ./conftest$ac_exeext
configure:19862: $? = 137 configure: program exited with status 137
>
>> Nice catch - but I can't tell which file open failed?
>
> It looks pretty clear to me that libgcc_s.so.1 was the file that
couldn't
> be found.  One question is exactly where that lives on your machine.
Presumably it exists someplace, else the build of OpenSSL should've
failed.

That's what I thought - just dismissed it because I know it is there:

sh-3.00# find / -name libgcc_s.so.1
/usr/local/lib/libgcc_s.so.1
/usr/local/lib/sparcv9/libgcc_s.so.1

>>> Since you say this doesn't happen when SSL support isn't requested, I
>>>  suppose that the problem has to do with libssl.so attempting to
>>> reference libgcc_s.so.  Beyond that, hard to say, but I bet there is
an rpath problem at the bottom of it.
>
>> Could it be trying to hit the stock OpenSSL libs installed with
Solaris, instead of my 64-bit version? I thought the LDFLAGS would have
prevented that.
>
> I'm not a Solaris user, but I'd be kinda surprised if Solaris' own
libraries were built with gcc --- Sun has their own compiler no? I think
it's finding your custom libssl just fine but the subsequent requirement
of libgcc_s is somehow not working.  ldd or local equivalent might help
debug this.

bash-3.00# ldd /usr/local/lib/sparcv9/libgcc_s.so.1
        libc.so.1 =>     /lib/64/libc.so.1
        libm.so.2 =>     /lib/64/libm.so.2
        /platform/SUNW,Ultra-80/lib/sparcv9/libc_psr.so.1

This is baffling me. Everything seems in place - but something is wrong.
What about including OpenSSL support could be doing this?

I just compiled Apache 2.2.9 with SSL and it went fine:

bash-3.00# file httpd
httpd:          ELF 64-bit MSB executable SPARCV9 Version 1, dynamically
linked, not stripped, no debugging information available

Thanks,
Randy

PS Your mail server bounced my message... called me a spammer! :-)



pgsql-general by date:

Previous
From: Taras Kopets
Date:
Subject: Re: storing repeating dates / events
Next
From: Tom Lane
Date:
Subject: Re: 64-bit Compile Failure on Solaris 10 with OpenSSL