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

From Tom Lane
Subject Re: 64-bit Compile Failure on Solaris 10 with OpenSSL
Date
Msg-id 27830.1220846810@sss.pgh.pa.us
Whole thread Raw
In response to Re: 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  ("Randal T. Rioux" <randy@procyonlabs.com>)
List pgsql-general
"Randal T. Rioux" <randy@procyonlabs.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

pgsql-general by date:

Previous
From: Ow Mun Heng
Date:
Subject: varchar vs Text & TOAST
Next
From: "Justin Graf"
Date:
Subject: Re: Very weird problem of "order by" in postgresql