On Mon, September 8, 2008 9:38 am, Randal T. Rioux wrote:
> On Mon, September 8, 2008 12:06 am, Tom Lane wrote:
>> "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.
>
> 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 :-)
Found a kludgy fix!
cp /usr/local/lib/sparcv9/libgcc_s.so.1 /usr/sfw/lib/sparcv9/
Now, both OpenSSL and PostgreSQL work great. In 64-bit mode.
If anyone has a less hack-ish solution, please share.
Thanks!
Randy
