Hi list, I was trying to run CL+SSL on OpenMCL on a Mac/Intel machine. However, it fails to find the shared library libssl.so. I checked the list archives, and I noted the problems of e.g. trying to link in 32-bit libraries. But this seems to be different: the library does exist, and it is 64 bit, but it does not exist under the name libssl.so -- it's libssl.dylib. The problem, as far as I can tell, is that the cffi-openmcl.lisp file defines the following: (eval-when (:compile-toplevel :load-toplevel :execute) (mapc (lambda (feature) (pushnew feature *features*)) '(;; OS/CPU features. #+darwinppc-target cffi-features:darwin #+unix cffi-features:unix #+ppc32-target cffi-features:ppc32 #+x8664-target cffi-features:x86-64 ))) And the default suffix for unix is .so, not .dylib. The problem is that load-foreign-library from libraries.lisp only tries to grab the default suffix (which in this case is .so) and then fails to find the .dylib library. I tried fixing it by changing the #+unix line above to use cffi-features:darwin, but I still got the 'unable to load' message. I followed Gary Byers' suggestion and ran lipo, and got: $ lipo -info /usr/lib/libssl.dylib Architectures in the fat file: /usr/lib/libssl.dylib are: i386 ppc I also installed the same library using darwinports and that one gives me this: $ lipo -info /opt/local/lib/libssl.dylib Non-fat file: /opt/local/lib/libssl.dylib is architecture: i386 This is all on a 64-bit enabled processor. But I have no problem loading up the above libraries from e.g. C code. Is it reasonable to conclude that I will have to compile 64-bit versions of these libraries, name them .so, and load those? Is there a better way of doing this? Please let me know if there is any more information I can provide. Thanks for your help, - David