rktboot error on aarch64-linux

[LiberalArtist]

According to Guix CI, bootstrapping Raket's Chez Scheme fork fails with an error from string-append. Here's the tail of the build log:

starting phase `build'
Assuming current directory has Chez Scheme sources
string-append: contract violation
  expected: string?
  given: #f
  argument position: 1st
  other arguments...:
   ".def"
  context...:
   /tmp/guix-build-racket-bootstrap-chez-bootfiles-8.2.drv-0/racket-minimal-8.2-checkout/racket/src/ChezScheme/rktboot/machine-def.rkt:6:0: open-file-with-machine.def-redirect
command "/gnu/store/1m10cjmip18isdxf0bljq733brq2gg9p-racket-minimal-bc-3m-8.2/bin/racket" "rktboot/main.rkt" "--dest" "/gnu/store/xlsnnphcqn1xxp2yqr519jh9sv0ai9xw-racket-bootstrap-chez-bootfiles-8.2" failed with status 1
builder for `/gnu/store/xg8sa6qssr46n5n887bzb5l3cl78fy52-racket-bootstrap-chez-bootfiles-8.2.drv' failed with exit code 1
@ build-failed /gnu/store/xg8sa6qssr46n5n887bzb5l3cl78fy52-racket-bootstrap-chez-bootfiles-8.2.drv - 1 builder for `/gnu/store/xg8sa6qssr46n5n887bzb5l3cl78fy52-racket-bootstrap-chez-bootfiles-8.2.drv' failed with exit code 1

The offending string-append seems to be here:

racket/racket/src/ChezScheme/rktboot/machine-def.rkt

Line 10 in 4f0e170

(define def (string-append target-machine ".def"))

I don't know if target-machine being #f is indicative of a broader problem inferring the target machine or not. A further complication is that I don't have an aarch64-linux setup myself, though I could try to get something working via QEMU.

I hope this problem isn't specific to Guix, but the build is driven by this Guile code, which I can (hopefully) explain if necessary: https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/racket.scm

[garrgravarr]

I researched what causes this error, and it seems to be a Guix problem. The package 'chez-scheme-for-racket-bootstrap-bootfiles' (where the above error occurs) bypasses the standard build process, but fails to set the machine architecture when the arch is natively supported by the Racket fork of Chez but not the original Chez distribution.
I sent a patch to the Guix issue tracker which should fix this (https://issues.guix.gnu.org/62231). I hope this will be picked up in a few days.

[LiberalArtist]

Thanks @garrgravarr for digging deeper in this! Guix may want to adopt the patch you sent, but I think this is a Racket/rktboot bug. Specifically, I think the problem is this code (which the details you found helped me to track down), which infers the machine type when none is specified:

racket/racket/src/rktboot/config.rkt

Lines 18 to 31 in e8b957c

	(define target-machine (or (hash-ref ht 'make-boot-targate-machine #f)
	(getenv "MACH")
	(case (system-type)
	[(macosx) (if (eqv? 64 (system-type 'word))
	"ta6osx"
	"ti3osx")]
	[(windows) (if (eqv? 64 (system-type 'word))
	"ta6nt"
	"ti3nt")]
	[else
	(case (path->string (system-library-subpath #f))
	[("x86_64-linux") "ta6le"]
	[("i386-linux") "ti3le"]
	[else #f])])))

This code will fail on any architecture but i386 or x86_64 and on any kernel but Windows, Mac, or Linux (so e.g. FreeBSD and OpenIndiana/Illumos/Solaris would not work, to name two platforms where I know packagers would love a better solution for generating Chez Scheme bootfiles).

The simple solution would be to use (system-type 'os*) and (system-type 'arch) here, but they were added in 7.9.0.6, and it seems like it would be nice to continue supporting pre-8.0 versions of Racket (i.e. versions when Racket BC was the default) if it isn't too much of a pain.

Of course, parsing more cases of (system-library-subpath #f) is possible, though tedious. Moreover, it would still require a manual update every time support for a new machine type is added. That's rare enough not to be a lot of work, but it's also rare enough that it seems hard to keep track of everywhere that needs to be updated.

I have written code to translate from more usual (say, config.sub-style) architecture and OS names to Chez machine types more than once, and I know there are implementations for raco cross, the build scripts in this repository, and maybe other places. I have wished for a more elegant way to define this mapping once and for all, but I'm not sure what it should be. Even an association list that could be included might be a help.

[LiberalArtist]

Tangentially, one of the notable differences between upstream Chez Scheme and Racket's branch is the change from a fixed, closed set of supported os–architecture pairs to a more open set. The pb variants are a big part of this, but so is the refactoring to use unix.def instead of requiring an explicit file for every machine type. For example, trv64qnx is not a useful machine type at the moment, since QNX doesn't seem to support RISC-V, but, if QNX gained RISC-V support, Racket's Chez should "just work". It's a great improvement overall, but there are a few places like this one where I've found some friction between the build process relating to the change.