Open larceny-trac-import opened 11 years ago
kaveman-
commented
9 years ago can't seem to find the patch. Has it been merged? I'd like to get binaries for NetBSD and Solaris x86 (Illumos, as found on OmniOS and SmartOS). The download page reads "Petit Larceny can also be built from source code for several other Unix platforms.". How does one go about bootstrapping on a new platform? Is cross-compilation from one platform to another supported?
WillClinger
commented
9 years ago I can't find the patch either, nor can I find any evidence of it having been merged. I suspect we lost the patch during the move from Trac to GitHub.
If I'm reading Jed Davis's report correctly, his first paragraph probably explains most of what has to be done to get Larceny built on NetBSD. After he got Larceny built on NetBSD, he "went in and added NetBSD as its own OS...This involved changes to a lot of different places..."
There are two ways to port Larceny to a new platform. Cross-compilation is one way, and the other is to build Larceny directly on the new platform using an implementation of Scheme other than Larceny that already runs on the new platform. It sounds as though Davis used PLT-R5RS as the host to build native Larceny on NetBSD, and then used native Larceny on NetBSD to build Petit Larceny on NetBSD.
We no longer support a build process that uses any implementations other than Larceny, but that's just because our support for non-Larceny systems has succumbed to bit rot. PLT Scheme, for example, has become Racket, which is said to be a language similar to but distinct from Scheme. It might be possible to locate a copy of PLT Scheme circa 2009 (or MzScheme v370) and use that to build Larceny on NetBSD.
Otherwise you will probably have to cross-compile. Cross-compilation isn't automated, but it's similar to a normal build, which I'll assume you've done. Larceny's build process is divided into stages. Most of those stages can be performed on a machine that already runs Larceny. The more similar that machine is to your target machine, the better; for NetBSD or Solaris x86, you should be able to use an x86 machine running Linux and a standard binary distribution of native Larceny for Linux x86.
You should start by downloading Larceny's source onto both the target machine and the machine you're going to use for cross-compilation. On the machine that's already running Larceny, you start out as though you're going to do a full build for that machine:
% larceny
Larceny v0.98 "General Ripper" (Mar 7 2015 01:06:26, precise:Linux:unified)
larceny.heap, built on Sat Mar 7 01:06:50 EST 2015
> (load "setup.sch")
> (setup 'sassy 'always-source)
Loading Larceny compatibility package.
src/Compat/Larceny/compat2.sch
src/Compat/Larceny/tobytevector-el.sch
lib/Base/list.sch
lib/Base/pp.sch
src/Build/expander.sch
src/Build/config.sch
#t
> (build-config-files)
src/Rts/features.schThat last bit, the call to (build-config-files), may be a little confusing. It doesn't create src/Rts/features.sch, but uses that file and several others to create src/Rts/c-table.c, src/Rts/nasm-table.asm, src/Rts/Shared/arithmetic.c, and several header files in the include directory. Those generated files will probably be okay; if you need to change them, however, you'll want to change the files used to generate them, which are identified by comments at the head of each generated file.
You'll need to copy those generated files to your target machine. It will probably be easier for you to copy the entire directory than to locate all of the generated files, and that's fine.
The next step is to load Larceny's compiler, use it to compile the Scheme code that will go into the bootstrap heap image, and create that bootstrap heap image:
> (load-compiler)
> (build-heap)Both of those procedure calls print a lot of stuff to let you know what they're doing, including a few warnings. When that's done, you'll need to copy the newly created heap image to your target machine; once again, it's okay to copy the entire directory to your target machine.
Before going on to the next step, you might want to remove src/Rts/Makefile if it's present.
Then:
> (build-runtime)That compiles Larceny's C code on your cross-compilation machine, creating a bunch of *.o files you should throw away. It also generates src/Rts/Makefile, which you should copy over to the src/Rts directory of your target machine. You will probably need to edit that Makefile for your target machine; for example, Jed Davis said he had to remove the -ldl option. After editing the Makefile, use it to compile Larceny's C code on your target machine.
If all goes well, you should now have src/Rts/larceny.bin on your target machine. Copy it to Larceny's top-level directory on your target machine, which should also contain the bootstrap heap image. Then copy src/Build/Scripts/larceny.sh to that top-level directory, and rename it to larceny. At this point, you should be able to run the cross-compiled bootstrap version of Larceny on your target machine by invoking the larceny.bin executable with the bootstrap heap image, but the larceny script won't work because you haven't yet created the standard heap image.
To complete the process, go back to your cross-compilation machine and compile the Scheme code that will go into the standard (non-bootstrap) Larceny heap image:
> (build-larceny-files)
> (exit)That creates a bunch of *.fasl files, which you should copy over to your target machine, placing each in the corresponding subdirectory. Here you need to be a bit careful, because it is not okay to overwrite the entire Larceny directory on the target machine now that you've constructed a bootstrap version of Larceny on it. (Once you have the bootstrap version of Larceny running on your target machine, I think you should be able to make a full copy of it and use that copy to repeat all of the previous steps on the target machine. If so, then that might be easier than compiling on the cross-compilation machine.)
On your target machine, you are now ready to construct the final heap image:
% "./larceny.bin" -stopcopy -- src/Build/iasn-larceny-heap.fasl
...
> (exit)You'll want to run the tests in test/Lib and test/Compiler at the very least. If all is well, you can compile the R7RS runtime on your target machine:
% ./larceny
Larceny v0.98+ "General Ripper" (<date and time>, precise:Linux:unified)
larceny.heap, built on <date and time>
> (require 'r7rsmode)
> (larceny:compile-r7rs-runtime)
> (exit)You'll want to run the tests in test/R7RS and its subdirectories. And you'll want to celebrate.
Reported by: jld on Thu Sep 10 18:11:42 2009 Getting Larceny to build on NetBSD is, as I noted on the mailing list, mostly just a matter of removing
-ldlfrom the linker invocations (the<dlfcn.h>routines are provided in the dynamic linker itself) and recognizing the machine nameamd64inffi-load.sch.However, this yields a build that thinks of itself as running on
"Linux", which aside from being slightly disconcerting might cause something out in experimental FFI land to make erroneous assumptions, I think?So I went in and added NetBSD as its own OS; diff against 0.97 is attached. This involved changes to a lot of different places, found mostly by
grepand visual inspection and also some trial-and-error. I've gotten the Sassy and Petit builds to work, hosted under PLT-R5RS resp. Larceny itself, on x86. The Petit build doesn't add-m32and so won't work on anamd64build host, but if I recall correctly it has that problem on Linux as well. I have not investigated other architectures at the time of this writing.