Re: 64-bit Compile Failure on Solaris 10 with OpenSSL

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

In response to

Responses

Browse pgsql-general by date

  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