From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Randal T(dot) Rioux" <randy(at)procyonlabs(dot)com> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: 64-bit Compile Failure on Solaris 10 with OpenSSL |
Date: | 2008-09-08 04:06:50 |
Message-ID: | 27830.1220846810@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
"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.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Justin Graf | 2008-09-08 04:39:24 | Re: Very weird problem of "order by" in postgresql |
Previous Message | Ow Mun Heng | 2008-09-08 03:58:24 | varchar vs Text & TOAST |