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@xxxxxxxxxxxxxxx> 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
