Yes, I've got a working build using the Mac OS X counterpart of dlopen and
I can provide a native Mac OS X binary (for instance, the final output named
`saved_gcl'), albeit a partially featured one (native relocation doesn't work
yet). I can also provide hints for anyone interested in compiling GCL for
Mac OS X.
For now, the executable that (si::save-system) produces occupies more disk
space than required, due to some limitations of the Mac OS X implementation
of unexec, and I'm currently attempting to cut its size down.
I haven't investigated native relocation yet, but I guess it shouldn't be too
difficult to get it to work, using Mac OS X dynamic loader APIs. I was asking
for further insight on relocation in a previous post (dated July 20) but I've
received no answer. I will have a clearer picture of what is needed, once I've
looked at how this is done for elf. For my information, is native relocation
supported for NeXT (see NeXTunixfasl.c) ?
Cheers,
Aurelien
> GCL is fully supported on Debian powerpc, and builds maxima and acl2
> there passing all tests. My understanding is that there is some
> 'fink' mechanism for running such packages under mac os-X, and if so
> this is my recommendation. You can grab the powerpc deb from
> ftp://> ftp.debian.org/debian/pool/main/g/gcl .
> We have a gcl developer working on a native mac os-X port, but it is
> likely that it will not be able to natively relocate .o files at
> first, meaning that one cannot load .o files, save-system, and then
> find them on re-execution of the image. This is a little annoying,
> but not fatal, as one can build gcl binaries in an alternate fashion
> using (compiler::link ...). Currently, GCL ships maxima and acl2
> using this mechanism on 5 Debian platforms, mips(el), alpha, ia64, and
> hppa.
> If there is remote ssh access to such a box, I might be able to get a
> native build going.