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