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@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@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
____________________ Racket Users list: http://lists.racket-lang.org/users
