[cffi-devel] Default library suffix for OS X / Intel under OpenMCL
David Haley
dchaley at gmail.com
Tue Jul 17 23:33:51 UTC 2007
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
More information about the cffi-devel
mailing list