John P Weatherman wrote:
> It would also be helpful to know what your LD_LIBRARY_PATH looks like
> and if you can do a 'find / -name libpq.so -print' to see where all the
> copies of this library may reside.
>
>>
>> Yeap, it's a fine place for it.
>>
>>
>
>
>
Sorry for the quick post but I was rushing during lunch and I can't get
gmail to work from work. Blocked on our proxy apparently :-(
Here is the LIBRARY_PATH
# echo $LD_LIBRARY_PATH
/usr/local/ssl98k/lib:/usr/lib/amd64:/usr/sfw/lib/64:/usr/local/lib:/usr/sfw/lib:/usr/openwin/lib
I've switched it all around to hopefully help find stuff. And btw, the
ssl98k is a new 64 build I put together. There were errors using the
one that came with solaris... weird. I'll write it down if interested.
I figured the latest build should resolve any problems. And btw, ssl98k
works great by itself. Seems pretty stable.
Here is how I run configure
# ./configure --prefix=/usr/local/postgres CC="cc -m64
-I/usr/local/ssl98k/include -L/usr/local/ssl98k/lib
-I/usr/local/include" --with-openssl
This runs fine however when I run make then try running pg_ctl (for
example) here is the error I get
/usr/local/postgres/bin/pg_ctl --help
ld.so.1: pg_ctl: fatal: relocation error: R_AMD64_32: file
/usr/local/postgres/lib/libpq.so.5: symbol (unknown): value
0xfffffd7fff1ccad0 does not fit
Killed
Thoughts on what I am doing wrong?
And openssl is confirmed at 64 bit.
# file openssl
openssl: ELF 64-bit LSB executable AMD64 Version 1, dynamically
linked, not stripped, no debugging information available
I have this working just fine under 64 bit without openssl. It's very
stable and all. But I do have a requirement to encrypt everything so I
have to go this route.
Thanks a bunch!!
