[Openmcl-devel] CCL/OpenMCL *features*

[Ron Garret]

FYI, and in case someone can shed some light on what I'm doing wrong,  
I tried adding :darwin to *features* in my ccl-init.lisp file but that  
did not fix the problem with cl+ssl.  The reason is (as far as I can  
tell) that cffi only looks at symbols in *features* that are interned  
in the cffi-features package.  So I had to push 'cffi-features::darwin  
onto lisp:*features* to get cl+ssl to work without modification.

rg

On Jan 4, 2008, at 11:11 AM, Gary Byers wrote:

> 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
>>>>>
>>>>>
>>>>
>>>
>>
>>
> _______________________________________________
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
> http://clozure.com/mailman/listinfo/openmcl-devel