There are periodic emailings on the list with Racket's openssl FFI dlopen
failing as it does not find the correct version. Specifically the
"SSLv23_client_method: implementation not found; no arguments provided"
failure.
The following email explains why a simple soft link does not solve this
issue. It appears to be an issue with library naming by the OpenSSL folks
and ldconfigs caching of the "latest" version.
http://sources.redhat.com/ml/libc-alpha/2004-09/msg00090.html
e.g. $ ln -s libssl.so.1.0.0.g libssl.so.1.0 won't work as ldconfig refuses
to cache it. One can verify with a ldconfig -p | grep ssl
I'm running Racket stuff on the AWS EC2 cloud and what one gets with the
standard EC2 Linux AMI is the following for SSL libraries.
[racket at ip-12-83-65-11 sp]$ ls /usr/lib/*ssl*
-rwxr-xr-x 1 root root 206648 Nov 11 22:50 /usr/lib/libssl3.so
lrwxrwxrwx 1 root root 16 Mar 15 18:30 /usr/lib/libssl.so.10 ->
libssl.so.1.0.0g
-rwxr-xr-x 1 root root 346784 Feb 2 17:29 /usr/lib/libssl.so.1.0.0g
[racket at ip-12-83-65-11 sp]$ ldconfig -p | grep ssl
libssl3.so (libc6) => /usr/lib/libssl3.so
libssl.so.10 (libc6) => /usr/lib/libssl.so.10
One option is to modify the Racket collection source and add
libssl.so.1.0.0g. But I suspect enumerable versions,
libssl.so.1.0.0h,i,j... et al to keep popping up pretty regular.
However, I assume on purpose for this very issue and not by typo, the
standard AWS EC2 Linux image provides a libssl.so.10 soft link (notice ten
"10" and not "1.0" ), which is lexically a later version as far as ldconfig
is concerned, hence is cached by ldconfig.
Given all that, I'm recommending that libssl.so.10 be added to the list
libraries sought by Racket's SSL FFI.
Ray
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.racket-lang.org/users/archive/attachments/20120316/de372947/attachment.html>