[Openmcl-devel] CCL/OpenMCL *features*

Gary Byers gb at clozure.com
Fri Jan 4 11:11:42 PST 2008


I think that :DARWIN should be on *features* on any version intended
to run on Darwin (and likewise the keywords :LINUX and :FREEBSD.) I'll
try to ensure that that's true in the next release (and get the changes
into CVS/SVN soon.)



On Thu, 3 Jan 2008, Bill Clementson wrote:

> Hi Gary,
>
> I added the "#+darwinx86-target :darwin" fix (in
> ccl:level-0;l0-init.lisp) and rebuilt ccl but cl+ssl still doesn't
> load libssl.dylib as it's supposed to. It appears that cffi
> (cffi-openmcl.lisp) puts the following into cffi-features:
> (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
>          )))
>

I think that I'd vote to have cffi-features:darwin set whenever
:DARWIN-TARGET is on features; :DARWIN-TARGET seems to be on
*FEATURES* pretty reliably.

(If there were a port to the iPhone - and there are no concrete
plans to do that here - which AFAIK is an ARM running Darwin,
then :DARWIN-TARGET/:DARWIN should be on that port's *FEATURES*.)


> If you intend to add the above :darwin fix to l0-init.lisp, then cffi
> should be patched as well (cffi-openmcl.lisp):
> (eval-when (:compile-toplevel :load-toplevel :execute)
>  (mapc (lambda (feature) (pushnew feature *features*))
>        '(;; OS/CPU features.
>          #+darwinppc-target  cffi-features:darwin
>          #+darwinx86-target  cffi-features:darwin
>          #+unix              cffi-features:unix
>          #+ppc32-target      cffi-features:ppc32
>          #+x8664-target      cffi-features:x86-64
>          )))
>
> If you don't intend to add the the above :darwin fix to l0-init.lisp,
> then cl+ssl needs to be patched instead. However, there will probably
> still be problems when other applications attempt to use cffi with ccl
> on Intel since cffi will default to using the :unix cffi-features
> values for libraries (and this will usually be incorrect). So, if you
> tell me what you plan to do vis-a-vis the above :darwin fix to
> l0-init.lisp, I'll be able to post the appropriate suggestion/fix on
> the cffi mailing list.
>
> Thanks,
> Bill
>
>
> On Jan 3, 2008 12:01 AM, Bill Clementson <billclem at gmail.com> wrote:
>> Ok, thanks for the quick response!
>>
>> - Bill
>>
>>
>> On Jan 2, 2008 7:54 PM, Gary Byers <gb at clozure.com> wrote:
>>> It's a bug (or at least an inconsistency); the code that initializes
>>> *FEATURES* based on what features were present at build time) adds
>>> :DARWIN if :DARWINPPC-TARGET was present but not if :DARWINX8664 was.
>>>
>>> Note that the the Darwin PPC case is the only one where there's a
>>> keyword on *FEATURES* that just names an OS (:DARWIN) without
>>> qualifying that as the host or target system.  The distinction
>>> between host and target usually only matters when cross-compiling,
>>> but there are no other cases where (for instance) :LINUX or :FREEBSD
>>> is on *FEATURS* to indicate the OS used by the host system (which
>>> for most people most of the time is exactly the same as the target.
>>>
>>> The initialization of *FEATURES* (in ccl:level-0;l0-init.lisp)
>>> probably passed the point of maintainability some time ago, and
>>> there are likely to be saner ways to do this.
>>>
>>>
>>>
>>> On Wed, 2 Jan 2008, Bill Clementson wrote:
>>>
>>>> Hi all,
>>>>
>>>> I converted over to an Intel Macbook Pro when Apple replaced my PPC
>>>> Powerbook last month (see http://bc.tech.coop/blog/071118.html for the
>>>> details). I installed the CVS version of CCL on my Macbook and most
>>>> things have been working fine (however, I'm still getting used to the
>>>> blazing speed difference!). One thing that didn't work fine was when I
>>>> tried to reinstall Hunchentoot. Hunchentoot has CL+SSL as a dependency
>>>> and CL+SSL uses CFFI to talk to libssl.dylib. However, the following
>>>> code in the cl+ssl reload.lisp file doesn't locate the libssl.dylib
>>>> library correctly:
>>>>
>>>> (cffi:define-foreign-library libssl
>>>>  (:windows "libssl32.dll")
>>>>  (:darwin "libssl.dylib")
>>>>  (:unix (:or "libssl.so.0.9.8" "libssl.so"))
>>>>  (t (:default "libssl3")))
>>>>
>>>> Instead, CFFI tries to load libssl.so.0.9.8" and "libssl.so" (e.g. -
>>>> the :unix libs) and fails because it doesn't find them. I had a look
>>>> at *features* and :darwin isn't defined but :unix is. I assume that
>>>> this is a change from OpenMCL 1.0? When I changed the above code to:
>>>>
>>>> (cffi:define-foreign-library libssl
>>>>  (:windows "libssl32.dll")
>>>>  (:darwin "libssl.dylib")
>>>>  (:unix (:or "libssl.so.0.9.8" "libssl.so" "libssl.dylib"))
>>>>  (t (:default "libssl3")))
>>>>
>>>> everything builds without problem. Is there some reason :darwin isn't
>>>> in *features* now?
>>>>
>>>> --
>>>> Bill Clementson
>>>> _______________________________________________
>>>> Openmcl-devel mailing list
>>>> Openmcl-devel at clozure.com
>>>> http://clozure.com/mailman/listinfo/openmcl-devel
>>>>
>>>>
>>>
>>
>
>



More information about the Openmcl-devel mailing list