The important part of the output you quoted was:
/usr/local/ssl/lib/libssl.a(s2_srvr.o) relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC
I've seen that error message many times when it is correct. So you would need to add -fPIC to the compile command and clean and rebuild libssl.a. Typically, there is a CFLAGS or similar environment variable that is input to the build process.
I've also see that error message when something else is wrong.
I forget what libssl is, so I'm not sure, but there may be better alternatives to rebuilding the .a, for example can you get a .so for that?
Edit: I checked the availability of libssl.a and libssl.so using yum provides
in Centos 5.3. Both are available and both would be installed in /usr/lib64 if you installed the right package.
I'm not certain, but I think the fact those are available in Centos 5.3 should mean they are available in RHEL 5.
Your failure occurred after finding libssl.a in /usr/local/ssl/lib
1) I think the command you used would have used libssl.so if it had found that and only used libssl.a because it didn't find libssl.so
2) The error message indicates that libssl.a was compiled in a way that allows it to be used only when linking into main executables and not when linking into .so files (which it thinks it is doing). I don't know if that should be considered a problem with the way libssl.a was compiled or whether you are always supposed to use libssl.so (which couldn't have this problem) in this situation.
3) Why do you have libssl.a in /usr/local/ssl/lib instead of in /usr/lib64 ?
I assume that means you installed libssl by some means other than the supported rpm, either instead of or in addition to the supported rpm. If you had a good reason for installing a non standard libssl, I think you still may have done so incorrectly. If you didn't have a good reason for installing a non standard libssl, I think you ought to get rid of it and install the standard package.