[Openmcl-devel] Clozure CL 1.3-RC1 available\
gb at clozure.com
Fri Feb 13 15:17:01 UTC 2009
On Thu, 12 Feb 2009, Bruce O'Neel wrote:
> 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
We don't magically catch NSExceptions on ppc64 yet, so doing anything
that causes one to be raised will have undefined (and probably unpleasant)
> 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
>  Clozure CL kernel debugger: k
> 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.
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!
> 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"
>> one of "linuxx86", "freebsdx86", "solarisx86", "windows", "darwinppc",
>> Both 32 bit and 64 bit binaries are included with all versions.
>> Openmcl-devel mailing list
>> Openmcl-devel at clozure.com
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
More information about the Openmcl-devel