From: | "Randal T(dot) Rioux" <randy(at)procyonlabs(dot)com> |
---|---|
To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: 64-bit Compile Failure on Solaris 10 with OpenSSL |
Date: | 2008-09-08 13:38:45 |
Message-ID: | 243476334b240c7e4125f44a67621c11.squirrel@meteor.procyonlabs.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Mon, September 8, 2008 12:06 am, Tom Lane wrote:
> "Randal T. Rioux" <randy(at)procyonlabs(dot)com> writes:
>> bash-3.00# ldd /usr/local/ssl/lib/libssl.so
> ...
>> libgcc_s.so.1 => (file not found)
>
> Smoke, meet gun ...
>
>> Now why would libssl.so not be linked to libgcc_s.so.1? Why would
>> PostgreSQL care and not Apache?
>
> Well, it is "linked", but the question is whether the dynamic linker
> can find it. Different systems do this in different ways and I'm not
> real familiar with how Solaris does it. The ideal thing to my mind is
> to embed a linker search path in libssl.so so that its dependencies can
> be found reliably, but I am not sure whether or how Solaris can do that.
>
> It may be that the reason Apache works is that it sets LD_LIBRARY_PATH
> or LD_RUN_PATH or some such environment variable that the dynamic linker
> pays attention to. I can't say that I find that a reliable or secure
> way to fix it, though.
Well, that would explain this:
-bash-3.00$ /usr/local/ssl/bin/openssl
ld.so.1: openssl: fatal: libgcc_s.so.1: open failed: No such file or
directory
Killed
Apache compiled with it, but yes - I looked through the scripts and
configure logs and the paths were set by it correctly.
I will mess with it more tonight and report my findings. Again, thanks for
listening to me think out loud :-)
Randy
From | Date | Subject | |
---|---|---|---|
Next Message | Urciolo, Kevin | 2008-09-08 15:20:28 | Postgres 8.3.1 RowExclusiveLock With JDBC XA |
Previous Message | bbeyer | 2008-09-08 13:17:49 | Possible limit on transaction size? |