[Openmcl-devel] Clozure CL 1.3-RC1 available\

[Bruce O'Neel]

Hi,

Thanks for the response. 

I didn't expect that 64 bit on a G5 tiger would work with
cocoa.  I seem to remember that the 64 bit support in Tiger 
didn't do the GUI bits.

Thanks for the vdso tip.  

cheers

bruce

On Fri, Feb 13, 2009 at 08:17:01AM -0700, Gary Byers wrote:
>
>
> On Thu, 12 Feb 2009, Bruce O'Neel wrote:
>
>> Hi,
>>
>> Great.  I tested it on a number of systems (where 'tested' means it builds itself with
>> (rebuild-ccl :full t) and on the Macs's the cocoa application builds with
>> (require "COCOA-APPLICATION") and then I ran a few different commands etc.
>>
>> Linux ppc - Debian lenny works fine.
>> DarwinPPC - Leopard - works fine on a G4
>>            Tiger - 32 bit completely works on a G5, 64 bit doesn't build the cocoa-application
>
>>                    but I suspect that isn't a suprise.
>
> Tiger didn't offer 64-bit Cocoa (or Carbon) libraries for PPC or x86.
>
> Leopard does, but (for a variety of reasons) the runtime support that
> the ObjC bridge needs has never really been implemented on ppc64 in a
> way that'd work with the released Leopard.  (It worked with an early
> Leopard beta, but didn't keep up with changes introduced in later betas
> and the Leopard release.)
>
> It's now closer to fully working: the IDE basically builds and starts
> up on ppc64 Leopard.  What doesn't work yet is some low-level stuff
> that tries to integrate the ObjC exception mechanisms with the CL
> condition system.  On platforms where this works, doing something that 
> causes an NSException to be raised - like trying to send an
> unrecognized message to an NSObject (no-applicable-method, kindof)
> will cause a lisp condition to be signaled, and in general we're able
> to unwind stacks and run cleanup code as we transition between lisp
> and ObjC.
>
> We don't magically catch NSExceptions on ppc64 yet, so doing anything
> that causes one to be raised will have undefined (and probably unpleasant)
> results.
>
>
>> Linuxx86  - Fedora Core 7 on a 64 bit processor, both 32 and 64 bit work fine.
>>            Fedora Core 7 on the same CPU, but in 32 bit mode.
>>
>> Unhandled exception 11 at 0x14061a71, context->regs at #xbfb7ebd8
>> ? for help
>> [5158] Clozure CL kernel debugger: k
>> Killed
>> Exit 137
>
> Short version: if you do (as root)
>
> shell# sysctl -w vm.vdso_enabled=0
>
> on FC7, the lisp seems to start up and run without any obvious problem.
>
> Longer version:
>
> We ran into something very similar on x86-64 Linux (IIRC, it was around
> the time that 2.6.23 was introduced, and around the time that Fedora 8
> was released.)  This had to do with a special shared library (a "vdso")
> being loaded by the Linux kernel, but the kernel not bothering to
> adjust some fields in some dynamic linker data structures (some things
> that're expected to be absolute addresses were left as relative offsets.)
>
> On x86-64, those relative offsets were negative, so we could heuristically
> detect this case and add the offset to the load-time address of the library.
> On 32-bit FC7, the offsets are non-negative and the load-time address of
> the library is recorded as 0, so there's no good way to make sense of
> things.  (I think that it might be reasonable to guess that the whole
> vdso mechanism was pretty new as of FC7 ...)
>
> For "real" (non-virtual) dynamic shared objects, the linker keeps track
> of the pathname from which the library is loaded; for the vdso, this
> pathname is "".  I think that it'd be perfectly reasonable for the lisp 
> code that grovels around in dynamic linker data structures trying
> to figure out what libraries are loaded to ignore any library that
> wasn't really loaded from a file.  There's little benefit in knowing
> anything about the vdso, and we can't trust the dynamic linker data
> structures associated with it.
>
> Until the lisp is changed to ignore the vdso, the workaround suggested
> above (using sysctl to keep it from being loaded) seems to work fine.
> (The name of the sysctl parameter might be a little different on different
> kernels; I don't know.)
>
>
>>
>> Thanks very much!
>>
>> cheers
>>
>> bruce
>>
>>
>> On Thu, Feb 12, 2009 at 02:43:08AM -0500, R. Matthew Emerson wrote:
>>> Release candidate binaries and sources for Clozure CL 1.3 are now
>>> available via Subversion.
>>>
>>> Release notes are available at http://trac.clozure.com/ccl/wiki/ReleaseNotes/1.3
>>>
>>>  From the release notes:
>>>
>>> Clozure CL now runs on the following platforms:
>>>    * Mac OS X 10.4 and later (PowerPC and x86)
>>>    * Linux (PowerPC and x86)
>>>    * FreeBSD 6.x and later (x86)
>>>    * Solaris (x86)
>>>    * MS Windows (x86)
>>>
>>> The preferred way to get Clozure CL is via Subversion.  For example,
>>> to get CCL for Mac OS X on x86, one would run the following command
>>> from a shell prompt:
>>>
>>> $ svn co http://svn.clozure.com/publicsvn/openmcl/release/1.3/darwinx86/ccl
>>>
>>> Versions for other platforms are available by changing the "darwinx86"
>>> to
>>> one of "linuxx86", "freebsdx86", "solarisx86", "windows", "darwinppc",
>>> or
>>> "linuxppc".
>>>
>>> Both 32 bit and 64 bit binaries are included with all versions.
>>>
>>> _______________________________________________
>>> 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
>>
>>