[Openmcl-devel] Porting

rjs at fdy2.demon.co.uk rjs at fdy2.demon.co.uk
Tue May 17 06:46:10 PDT 2011

Gary Byers wrote:
>On Fri, 13 May 2011, rjs at fdy2.demon.co.uk wrote:
>> Is there any documentation on how best to debug a port to a new platform ?
>> I'm trying to build CCL for NetBSD/amd64.
>> I have built the lisp-kernel stuff and tried running it with a Linux
>> X86-64 image but it just drops into the debugger.

>When he was working on the x8632 port, Matt wrote a wiki page (on the
>trac wiki) that described the process.  I took a quick look for it
>and couldn't find it, but I'm sure that it's still there and someone
>may remember the URL ...


>What you're generally going to need to do is to cross-compile a set
>of NetBSD fasl files and a NetBSD bootstrapping image from some host
>machine on which CCL already runs.  Once you've done that, you copy
>everything over to the target system, tell the NetBSD kernel to
>start with the bootstrapping image, watch it load a few dozen FASL
>files, save a full heap image, then sit back and congratulate yourself.
>(This may take several iterations, and it's sometimes more practical
>to NFS-mount the host's CCL directory on the target to avoid having
>to copy things around as often.)  In theory, it should be possible
>to use any platform on which CCL already runs as the host; in practice,
>it may work better if the host and target share the same word size
>and endianness.

Would it be possible for someone to check that the instructions for
cross compiling are complete ?

I have tried modifying what is at
<http://trac.clozure.com/ccl/wiki/CrossCompiling> but I don't get
anything in *KNOWN-BACKENDS* other than the host one.

I'm doing:

  (pushnew :netbsd-target *features*)
  (pushnew :netbsdx86-target *features*)
  (pushnew :netbsdx8664-target *features*)

  (in-package "CCL")
  (require-update-modules *x86-compiler-modules* t)
  (require-update-modules *x8664-compiler-backend-modules* t)
  (require-update-modules *x86-compiler-backend-modules* t)
  (require-update-modules *x86-xdev-modules* t)
  (defpackage "X86-NETBSD64")
  (load "ccl:lib;ffi-netbsdx8664")
  (require-update-modules *x8664-xload-modules* t)
  (setup-x8664-ftd (find-backend :netbsdx8664))

I'm cross compiling from Solaris (under Xen).

>I'm fairly familiar with all of this stuff (I'm disturbingly familiar
>with some of it) and I think that it usually takes me about a week to
>port CCL to a new Unix variant.  I'm not trying to make this sound any
>more daunting than it is, but if you were expecting to be able to run
>a Linux image with a NetBSD kernel you've probably been discouraged
>from that idea.  If you have commercial interest in having CCL ported
>to NetBSD, Clozure could be persuaded to take money to do it for you.
>It's possible (though probably not too likely) that we'd just do the
>port ourselves someday.  (There was slight interest expressed in
>having CCL running on Solaris; porting to Solaris exposed some
>problems that could have affected other platforms, so the port was
>worthwhile even though the demand was slight.)

I wasn't expecting the Linux image to "just work", I only tried using
it as you had suggested doing that when the Solaris port was starting

>If you're interested in doing this yourself (as an exercise or for
>other reasons), I think that all of the above is essentially correct.
>I may be forgetting some details, but it's likely that details that
>I'm forgetting are similar to those that I described.  The overall
>effort involved is probably similar to what's involved in porting a
>medium-to-large application program to another OS.

I wanted a Lisp with native threads on NetBSD. I had been working on
trying to get SBCL to work and was looking at how other systems
mapped onto pthreads. Once I started poking around in CCL it
seemed worthwhile finding out whether I could get it to work too.

I don't have any commercial need for it. I am a NetBSD developer
and would like to see a good selection of Lisps available for it.

I also have several ARM systems and would like a Lisp for them, none
are ARMv6t2 though.

Robert Swindells

More information about the Openmcl-devel mailing list