Chez for architectures without native backends

That "host" is supposed to be "build", the same as when a file path is supplied. I'll push a fix.

I'm a bit confused about (at least) one aspect of cross-compiling Chez Scheme. I think this is unrelated to weather the host has a native backend or not, so I'm going to try to put the scenario in concrete terms.

Let's say I have a ta6le system and I've already built and installed Racket's variant of Chez Scheme. Now I want to cross-compile Chez for, say, ti3nt, and I have a fresh checkout of the Racket Git repository. How am I supposed to start?

IIUC, the cross build needs to run my ta6le Chez to compile the ti3nt bootfiles, but there doesn't seem to be a way to supply my existing Scheme. Do I need to unpack the bootfiles I created with rktboot to build my installed scheme, but not supply my installed scheme itself? It looks like the files equates.h,,,, created with the bootstrap bootfiles don't get installed by make install, so it seems like there isn't some part of the ta6le installation I could just copy into place.

I don't know if it's feasible, but I think the ideal scenario for me would be to create the ti3nt bootfiles similarly to the way I do for ta6le—but using my existing scheme, rather than Racket BC—then proceed with the rest of the cross build.

I do see that there are --host-workarea and --host-scheme Zuo arguments used by the Racket CS build, but I haven't figured out how to use them when just building Chez Scheme.

It would also be possible to keep around more from the ta6le, maybe even the whole workarea, if that would make things easier.

I've also tried building emulating powerpc64le-linux-gnu again (as opposed to cross-compiling), and it fails when trying to run rktboot with Racket BC:

phase `patch-generated-file-shebangs' succeeded after 0.0 seconds
starting phase `build'
qemu: uncaught target signal 6 (Aborted) - core dumped
error: in phase 'build': uncaught exception:
%exception #<&invoke-error program: "/gnu/store/d31g0znpk0k6r12049mpzq6z9203rh1d-racket-vm-bc-" arguments: ("rktboot/main.rkt" "--machine" "tpb64l") exit-status: #f term-signal: 6 stop-signal: #f> 
phase `build' failed after 0.2 seconds
command "/gnu/store/d31g0znpk0k6r12049mpzq6z9203rh1d-racket-vm-bc-" "rktboot/main.rkt" "--machine" "tpb64l" failed with signal 6
note: keeping build directory `/tmp/guix-build-chez-scheme-for-racket-bootstrap-bootfiles-'
builder for `/gnu/store/3pllg3rngm6djqfhpasi1f04r4i1k806-chez-scheme-for-racket-bootstrap-bootfiles-' failed with exit code 1
build of /gnu/store/3pllg3rngm6djqfhpasi1f04r4i1k806-chez-scheme-for-racket-bootstrap-bootfiles- failed
View build log at '/var/log/guix/drvs/3p/llg3rngm6djqfhpasi1f04r4i1k806-chez-scheme-for-racket-bootstrap-bootfiles-'.
cannot build derivation `/gnu/store/g32qimkk7hswak035m33khjm7xh711pa-chez-scheme-for-racket-': 1 dependencies couldn't be built
guix build: error: build of `/gnu/store/g32qimkk7hswak035m33khjm7xh711pa-chez-scheme-for-racket-' failed

When I tried to run the binary manually, I got a slightly more detailed error:

$ /gnu/store/d31g0znpk0k6r12049mpzq6z9203rh1d-racket-vm-bc- --version
Welcome to Racket v8.5.0.8 [bc].
SIGSEGV MAPERR si_code 1 fault on addr 0x40021cb3b8
qemu: uncaught target signal 6 (Aborted) - core dumped
Aborted (core dumped)

I don't know much about QEMU, but the SIGSEGV made me wonder if this might have to do with the GC write barrier on Racket BC. It's still surprising, though, because the raco setup for BC worked fine. Are there any known caveats to running BC under QEMU? Specifically, I'm using:

As you say, things are not really set up for that already, but it's not difficult to add. I'll add it.

That way is currently supported by make ti3le.bootquick in the ta6le workarea. But I can see how using an installed scheme would be easier for your setup.

I've gotten a little further with this, after figuring out an issue with my Guix recipe, but now the Chez build process is trying to run my cross-compiled scheme as part of the build process.

In more detail: I'm on x86_64-linux-gnu and trying to build tpb64l for powerpc64le-linux-gnu. With an existing ta6le build, I've used zuo makefiles/boot.zuo /my/installed/ta6le/scheme tpb64l (method 5) to generate a set of bootfiles. Then I've configured with these flags:

("--disable-x11" "--threads" "-m=tpb64l" "CFLAGS=-g -O2 -D_REENTRANT -pthread" "LIBS=-lm -ldl -lncurses" "--toolprefix=powerpc64le-linux-gnu-" "--installcsug=/gnu/store/zmkijfnk1nqsrwziflg861y57r21ddjc-chez-scheme-for-racket-" "--installreleasenotes=/gnu/store/zmkijfnk1nqsrwziflg861y57r21ddjc-chez-scheme-for-racket-" "--installprefix=/gnu/store/qs4rwfphpzj3aw50ij7v0iicby5p95gl-chez-scheme-for-racket-" "CPPFLAGS=-DGUIX_RKTIO_PATCH_BIN_SH=/gnu/store/q9pidl3hg9l0qga88gsgjs8brv82qy0v-bash-minimal-5.1.8/bin/sh" "ZLIB=-lz" "LZ4=-llz4" "--libkernel" "--nogzip-man-pages")

The C build steps then succeed, from:

powerpc64le-linux-gnu-gcc -DGUIX_RKTIO_PATCH_BIN_SH=/gnu/store/q9pidl3hg9l0qga88gsgjs8brv82qy0v-bash-minimal-5.1.8/bin/sh -DPORTABLE_BYTECODE -Itpb64l/boot/tpb64l -Itpb64l/c -I../ChezScheme/c/ -g -O2 -D_REENTRANT -pthread -o tpb64l/c/statics.o -c ../ChezScheme/c/statics.c

but then we get to the problem:

powerpc64le-linux-gnu-gcc -g -O2 -D_REENTRANT -pthread -o tpb64l/bin/tpb64l/scheme tpb64l/boot/tpb64l/main.o tpb64l/boot/tpb64l/libkernel.a -lm -ldl -lncurses -lz -llz4
: tpb64l/bin/tpb64l/scheme
running tpb64l/bin/tpb64l/scheme to build tpb64l/s/
exec failed
 in build-one
 in loop
 in module->hash
make: *** [Makefile:10: build] Error 1

Since tpb64l/bin/tpb64l/scheme was compiled for powerpc64le-linux-gnu, it doesn't run on x86_64-linux-gnu.

I'm not sure how to deal with this in general for cross-compiling Chez, but it seems especially likely for things to get confused when trying to cross-compile a pb variant that is also supported by the build machine. It seems like nothing in my configure flags communicates that this is supposed to be a cross build, and I'm not seeing any way to add that information, either.

Thanks to your fix for Internal error during `zuo . install` · Issue #4377 · racket/racket · GitHub, I've made more progress on minimal Racket CS, but I've hit a new error: the Racket BC passed to configure's --enable-racket= complains bad switch: --cross-compiler. I'll try using --enable-racket= with Racket CS, instead; I'm not sure if BC is intended or reasonable to work there or not.

compiler/cm:   finish-compile: /tmp/guix-build-racket-vm-cs-8.5.900.drv-0/source/racket/collects/setup/unixstyle-install.rkt
Copying collects -> /gnu/store/ddcdg56xlgfmqx7v79hjl42qzal9hms5-racket-vm-cs-8.5.900/opt/racket-vm/collects
Copying share/pkgs -> /gnu/store/ddcdg56xlgfmqx7v79hjl42qzal9hms5-racket-vm-cs-8.5.900/opt/racket-vm/share/pkgs
  missing source path "share/pkgs", skipping...
Copying share -> /gnu/store/ddcdg56xlgfmqx7v79hjl42qzal9hms5-racket-vm-cs-8.5.900/opt/racket-vm/share
  missing source path "share", skipping...
Copying doc -> /gnu/store/ddcdg56xlgfmqx7v79hjl42qzal9hms5-racket-vm-cs-8.5.900/opt/racket-vm/doc
  missing source path "doc", skipping...
Copying etc -> /gnu/store/ddcdg56xlgfmqx7v79hjl42qzal9hms5-racket-vm-cs-8.5.900/opt/racket-vm/etc
/gnu/store/nnwmpjkgsrnk9a3hanjs40rkjs6bdrsw-racket-vm-bc-8.5.900/opt/racket-vm/bin/racket -MCR cs/c/compiled: --cross-compiler tpb64l cs/c -X /gnu/store/ddcdg56xlgfmqx7v79hjl42qzal9hms5-racket-vm-cs-8.5.900/opt/racket-vm/collects -G /gnu/store/ddcdg56xlgfmqx7v79hjl42qzal9hms5-racket-vm-cs-8.5.900/opt/racket-vm/etc -N raco -l- setup --no-user
/gnu/store/nnwmpjkgsrnk9a3hanjs40rkjs6bdrsw-racket-vm-bc-8.5.900/opt/racket-vm/bin/racket: bad switch: --cross-compiler
Use the --help or -h flag for help.
 in build-one
 in loop
 in module->hash
make: *** [Makefile:16: install] Error 1
error: in phase 'install': uncaught exception:
%exception #<&invoke-error program: "make" arguments: ("install" "ZUO=/gnu/store/9li7zhdi70d7pjrk6dniknq2qib6m913-zuo-1.0-racket8.5.900-guix1/bin/zuo") exit-status: 2 term-signal: #f stop-signal: #f> 
phase `install' failed after 4.1 seconds
command "make" "install" "ZUO=/gnu/store/9li7zhdi70d7pjrk6dniknq2qib6m913-zuo-1.0-racket8.5.900-guix1/bin/zuo" failed with status 2

Cross compilation does require the same variant of Racket (BC vs. CS) as the target variant.

With that change, I have minimal Racket CS cross-compiling successfully for powerpc64-linux-gnu/tpb64l! The only remaining problem is with building Chez directly.

Reading the BUILDING file again, I found that I could use make kernel when cross-compiling to "compile just the C sources to produce the executable so that running can use existing bootfiles." This seems to have worked! I think there's room for improvement to make things go more smoothly, but I think this should be enough to let Guix start distributing Racket's Chez Scheme for all of Guix's supported architectures with the Racket 8.6 release.

One particular snag along those lines is make install-doc depends on make build, and would probably try to run the wrong scheme if it got that far.

A Guix user, Thiago Bauermann, reported a problem bootstrapping with "rktboot" on powerpc64le-linux:

I tried building the zuo branch from your gitlab repo (commit
00975c823227 “gnu: chez-scheme-for-racket: Suport all systems.” from
August 8th) on powerpc64le-linux and had this build failure in

starting phase `build'
Assuming current directory has Chez Scheme sources
Use /tmp/guix-build-chez-scheme-for-racket-bootstrap-bootfiles-
Use /tmp/guix-build-chez-scheme-for-racket-bootstrap-bootfiles-
Use /tmp/guix-build-chez-scheme-for-racket-bootstrap-bootfiles-
Check /tmp/guix-build-chez-scheme-for-racket-bootstrap-bootfiles-
Load nanopass
Apply nanopass patch
Load cmacros parts
Load enum
Load cprep
Load expander
Install evaluator
Load cmacros using expander
Continue loading expander
Initialize system libraries
Load nanopass using expander
Load priminfo and primvars
Load expander using expander
Initialize system libraries in bootstrapped expander
Declare nanopass in bootstrapped expander
Load some declarations
Load some declarations
Load some declarations
Load most declarations
Define $filter-foreign-type
Load mkheader
Generate headers
Load mkgc
Generate GC
error: in phase 'build': uncaught exception:
%exception #<&invoke-error program: "/gnu/store/f72x3mdyagp67ybwdy9cqqsid9v8jk9l-racket-vm-bc-8.6/opt/racket-vm/bin/racket" arguments: ("rktboot/main.rkt" "--machine" "tpb64l") exit-status: 1 term-signal: #f stop-signal: #f> 
phase `build' failed after 707.9 seconds
command "/gnu/store/f72x3mdyagp67ybwdy9cqqsid9v8jk9l-racket-vm-bc-8.6/opt/racket-vm/bin/racket" "rktboot/main.rkt" "--machine" "tpb64l" failed with status 1

I didn't have the chance yet to dig into why rktboot/main.rkt is
failing. If you have any tips on how to find more details on what is
going on (e.g., is there some verbose flag that can be passed to it?) I
can try to investigate.

I've confirmed that racket rktboot/main.rkt --machine tpb64l works for me (on x86_64-linux) both on the v8.6 tag and on current master, so I'm not sure what else to try. I did give them instructions for testing this outside of the Guix build environment, and I pointed them to this thread.

The problem with Racket BC on ppc64le seems to be in stack-overflow handling. I was able to get rktboot to complete by configuring the BC build with CPPFLAGS=-DSTACK_SAFETY_MARGIN=200000, but I don't know whether that's a complete or general solution.

1 Like

Thanks! I've adjusted my Guix package definition, and I'll ask Thiago to give it a try. This sounds like it may also explain my issue when I tried QEMU:

so I'll try that again, too.

(Once the update to Racket 8.6 is merged, Guix's build farm will also test ppc64le.)

I haven't heard back from anyone with actual hardware yet, but QEMU failed for me the same way as before both with CPPFLAGS=-DSTACK_SAFETY_MARGIN=200000 and, as an experiment, 10 times that. Of course, it could be that the issue under qemu-user-static is actually something different.

Thiago says that adding -DSTACK_SAFETY_MARGIN=200000 for BC did get rktboot working on ppc64le and apparently the Chez Scheme build succeeded. However, minimal Racket CS failed during make install by trying to do a raco setup using the BC Racket that had been supplied to --enable-racket=, but incorrectly passing it --cross-compiler. Here's part of the log:

starting phase `install'
/gnu/store/i9h1vc67h9148xvn8djk8j3smlkhaf09-zuo-1.0-racket8.6/bin/zuo . install DESTDIR=""
cp cs/c/racketcs /gnu/store/cb84hlf8gb0nspc8f6n7qhihsflj7k6x-racket-vm-cs-8.6/opt/racket-vm/bin/racket
: /gnu/store/cb84hlf8gb0nspc8f6n7qhihsflj7k6x-racket-vm-cs-8.6/opt/racket-vm/bin/racket
cp ../src/start/starter-sh /gnu/store/cb84hlf8gb0nspc8f6n7qhihsflj7k6x-racket-vm-cs-8.6/opt/racket-vm/lib/starter-sh
cp cs/c/starter /gnu/store/cb84hlf8gb0nspc8f6n7qhihsflj7k6x-racket-vm-cs-8.6/opt/racket-vm/lib/starter
: /gnu/store/cb84hlf8gb0nspc8f6n7qhihsflj7k6x-racket-vm-cs-8.6/opt/racket-vm/lib/starter
/gnu/store/w675i4y454bgcyr69fp672h51p24l1fg-racket-vm-bc-8.6/opt/racket-vm/bin/racket -O info'@'compiler/cm -l- setup --chain ../src/setup-go.rkt cs/c/compiled ignored cs/c/ignored.d ../src/start/collects-path.rkt ../src/ /gnu/store/cb84hlf8gb0nspc8f6n7qhihsflj7k6x-racket-vm-cs-8.6/opt/racket-vm/lib/starter ../collects ../etc
compiler/cm:   start-compile: /tmp/guix-build-racket-vm-cs-8.6.drv-0/source/racket/src/start/collects-path.rkt
compiler/cm:   finish-compile: /tmp/guix-build-racket-vm-cs-8.6.drv-0/source/racket/src/start/collects-path.rkt
/gnu/store/w675i4y454bgcyr69fp672h51p24l1fg-racket-vm-bc-8.6/opt/racket-vm/bin/racket -O info'@'compiler/cm -l- setup --chain ../src/setup-go.rkt cs/c/compiled ignored cs/c/ignored.d ../src/cs/c/gen-system.rkt /gnu/store/cb84hlf8gb0nspc8f6n7qhihsflj7k6x-racket-vm-cs-8.6/opt/racket-vm/lib/system.rktd tpb64l tpb64l machine ../src/cs/c/ ""
compiler/cm:   start-compile: /tmp/guix-build-racket-vm-cs-8.6.drv-0/source/racket/src/cs/c/gen-system.rkt
compiler/cm:   finish-compile: /tmp/guix-build-racket-vm-cs-8.6.drv-0/source/racket/src/cs/c/gen-system.rkt
cp ../src/cs/c/api.h /gnu/store/cb84hlf8gb0nspc8f6n7qhihsflj7k6x-racket-vm-cs-8.6/opt/racket-vm/include/racketcs.h
cp ../src/cs/c/boot.h /gnu/store/cb84hlf8gb0nspc8f6n7qhihsflj7k6x-racket-vm-cs-8.6/opt/racket-vm/include/racketcsboot.h
cp cs/c/ChezScheme/tpb64l/boot/tpb64l/scheme.h /gnu/store/cb84hlf8gb0nspc8f6n7qhihsflj7k6x-racket-vm-cs-8.6/opt/racket-vm/include/chezscheme.h
cd cs/c/repack && ar x ../rktio/librktio.a
cd cs/c/repack && ar x ../ChezScheme/tpb64l/boot/tpb64l/libkernel.a
ar rc cs/c/libracketcs.a cs/c/repack/expeditor.o cs/c/repack/schsig.o cs/c/repack/compress-io.o cs/c/repack/rktio_flock.o cs/c/repack/gc-par.o cs/c/repack/rktio_shellex.o cs/c/repack/flushcache.o cs/c/repack/new-io.o cs/c/repack/rktio_signal.o cs/c/repack/print.o cs/c/repack/rktio_fd.o cs/c/repack/symbol.o cs/c/repack/rktio_poll_set.o cs/c/repack/schlib.o cs/c/repack/rktio_fs.o cs/c/repack/scheme.o cs/c/repack/rktio_wide.o cs/c/repack/rktio_main.o cs/c/repack/rktio_dll.o cs/c/repack/prim.o cs/c/repack/gc-oce.o cs/c/repack/fasl.o cs/c/repack/ffi.o cs/c/repack/segment.o cs/c/repack/rktio_convert.o cs/c/repack/rktio_error.o cs/c/repack/thread.o cs/c/repack/number.o cs/c/repack/rktio_process.o cs/c/repack/gc-ocd.o cs/c/repack/gc-011.o cs/c/repack/rktio_sha1.o cs/c/repack/rktio_network.o cs/c/repack/rktio_file.o cs/c/repack/random.o cs/c/repack/prim5.o cs/c/repack/io.o cs/c/repack/rktio_syslog.o cs/c/repack/rktio_hash.o cs/c/repack/vfasl.o cs/c/repack/rktio_console.o cs/c/repack/intern.o cs/c/repack/rktio_pipe.o cs/c/repack/rktio_sleep.o cs/c/repack/gcwrapper.o cs/c/repack/stats.o cs/c/repack/rktio_fs_change.o cs/c/repack/rktio_envvars.o cs/c/repack/rktio_ltps.o cs/c/repack/statics.o cs/c/repack/rktio_sha2.o cs/c/repack/foreign.o cs/c/repack/pb.o cs/c/repack/alloc.o cs/c/repack/rktio_time.o cs/c/repack/rktio_cpu.o cs/c/boot.o
cp cs/c/libracketcs.a /gnu/store/cb84hlf8gb0nspc8f6n7qhihsflj7k6x-racket-vm-cs-8.6/opt/racket-vm/lib/libracketcs.a
: /gnu/store/cb84hlf8gb0nspc8f6n7qhihsflj7k6x-racket-vm-cs-8.6/opt/racket-vm/lib/libracketcs.a
cp cs/c/gracketcs /gnu/store/cb84hlf8gb0nspc8f6n7qhihsflj7k6x-racket-vm-cs-8.6/opt/racket-vm/lib/gracket
/gnu/store/w675i4y454bgcyr69fp672h51p24l1fg-racket-vm-bc-8.6/opt/racket-vm/bin/racket -O info'@'compiler/cm -l- setup --chain ../src/setup-go.rkt cs/c/compiled ignored cs/c/ignored.d ../src/start/collects-path.rkt ../src/ /gnu/store/cb84hlf8gb0nspc8f6n7qhihsflj7k6x-racket-vm-cs-8.6/opt/racket-vm/bin/racket ../collects ../etc
/gnu/store/w675i4y454bgcyr69fp672h51p24l1fg-racket-vm-bc-8.6/opt/racket-vm/bin/racket -O info'@'compiler/cm -l- setup --chain ../src/setup-go.rkt cs/c/compiled ignored cs/c/ignored.d ../src/start/collects-path.rkt ../src/ /gnu/store/cb84hlf8gb0nspc8f6n7qhihsflj7k6x-racket-vm-cs-8.6/opt/racket-vm/lib/gracket ../collects ../etc
/gnu/store/w675i4y454bgcyr69fp672h51p24l1fg-racket-vm-bc-8.6/opt/racket-vm/bin/racket -O info'@'compiler/cm -l- setup --chain ../src/setup-go.rkt cs/c/compiled ignored cs/c/ignored.d ../src/cs/c/add-terminator.rkt cs/c/petite-v.boot /gnu/store/cb84hlf8gb0nspc8f6n7qhihsflj7k6x-racket-vm-cs-8.6/opt/racket-vm/lib/petite.boot
compiler/cm:   start-compile: /tmp/guix-build-racket-vm-cs-8.6.drv-0/source/racket/src/cs/c/add-terminator.rkt
compiler/cm:   finish-compile: /tmp/guix-build-racket-vm-cs-8.6.drv-0/source/racket/src/cs/c/add-terminator.rkt
/gnu/store/w675i4y454bgcyr69fp672h51p24l1fg-racket-vm-bc-8.6/opt/racket-vm/bin/racket -O info'@'compiler/cm -l- setup --chain ../src/setup-go.rkt cs/c/compiled ignored cs/c/ignored.d ../src/cs/c/add-terminator.rkt cs/c/scheme-v.boot /gnu/store/cb84hlf8gb0nspc8f6n7qhihsflj7k6x-racket-vm-cs-8.6/opt/racket-vm/lib/scheme.boot
/gnu/store/w675i4y454bgcyr69fp672h51p24l1fg-racket-vm-bc-8.6/opt/racket-vm/bin/racket -O info'@'compiler/cm -l- setup --chain ../src/setup-go.rkt cs/c/compiled ignored cs/c/ignored.d ../src/cs/c/add-terminator.rkt cs/c/racket-v.boot /gnu/store/cb84hlf8gb0nspc8f6n7qhihsflj7k6x-racket-vm-cs-8.6/opt/racket-vm/lib/racket.boot
/gnu/store/w675i4y454bgcyr69fp672h51p24l1fg-racket-vm-bc-8.6/opt/racket-vm/bin/racket -O info'@'compiler/cm -l- setup --chain ../src/setup-go.rkt cs/c/compiled ignored cs/c/ignored.d ../collects/setup/unixstyle-install.rkt make-install-copytree ../ /gnu/store/cb84hlf8gb0nspc8f6n7qhihsflj7k6x-racket-vm-cs-8.6/opt/racket-vm/bin /gnu/store/cb84hlf8gb0nspc8f6n7qhihsflj7k6x-racket-vm-cs-8.6/opt/racket-vm/collects /gnu/store/cb84hlf8gb0nspc8f6n7qhihsflj7k6x-racket-vm-cs-8.6/opt/racket-vm/share/pkgs /gnu/store/cb84hlf8gb0nspc8f6n7qhihsflj7k6x-racket-vm-cs-8.6/opt/racket-vm/doc /gnu/store/cb84hlf8gb0nspc8f6n7qhihsflj7k6x-racket-vm-cs-8.6/opt/racket-vm/lib /gnu/store/cb84hlf8gb0nspc8f6n7qhihsflj7k6x-racket-vm-cs-8.6/opt/racket-vm/include /gnu/store/cb84hlf8gb0nspc8f6n7qhihsflj7k6x-racket-vm-cs-8.6/opt/racket-vm/lib /gnu/store/cb84hlf8gb0nspc8f6n7qhihsflj7k6x-racket-vm-cs-8.6/opt/racket-vm/share /gnu/store/cb84hlf8gb0nspc8f6n7qhihsflj7k6x-racket-vm-cs-8.6/opt/racket-vm/etc /gnu/store/cb84hlf8gb0nspc8f6n7qhihsflj7k6x-racket-vm-cs-8.6/opt/racket-vm/share/applications /gnu/store/cb84hlf8gb0nspc8f6n7qhihsflj7k6x-racket-vm-cs-8.6/opt/racket-vm/man yes
compiler/cm:   start-compile: /tmp/guix-build-racket-vm-cs-8.6.drv-0/source/racket/collects/setup/unixstyle-install.rkt
compiler/cm:   finish-compile: /tmp/guix-build-racket-vm-cs-8.6.drv-0/source/racket/collects/setup/unixstyle-install.rkt
Copying collects -> /gnu/store/cb84hlf8gb0nspc8f6n7qhihsflj7k6x-racket-vm-cs-8.6/opt/racket-vm/collects
Copying share/pkgs -> /gnu/store/cb84hlf8gb0nspc8f6n7qhihsflj7k6x-racket-vm-cs-8.6/opt/racket-vm/share/pkgs
  missing source path "share/pkgs", skipping...
Copying share -> /gnu/store/cb84hlf8gb0nspc8f6n7qhihsflj7k6x-racket-vm-cs-8.6/opt/racket-vm/share
  missing source path "share", skipping...
Copying doc -> /gnu/store/cb84hlf8gb0nspc8f6n7qhihsflj7k6x-racket-vm-cs-8.6/opt/racket-vm/doc
  missing source path "doc", skipping...
Copying etc -> /gnu/store/cb84hlf8gb0nspc8f6n7qhihsflj7k6x-racket-vm-cs-8.6/opt/racket-vm/etc
/gnu/store/w675i4y454bgcyr69fp672h51p24l1fg-racket-vm-bc-8.6/opt/racket-vm/bin/racket -MCR cs/c/compiled: --cross-compiler tpb64l cs/c -X /gnu/store/cb84hlf8gb0nspc8f6n7qhihsflj7k6x-racket-vm-cs-8.6/opt/racket-vm/collects -G /gnu/store/cb84hlf8gb0nspc8f6n7qhihsflj7k6x-racket-vm-cs-8.6/opt/racket-vm/etc -N raco -l- setup --no-user
/gnu/store/w675i4y454bgcyr69fp672h51p24l1fg-racket-vm-bc-8.6/opt/racket-vm/bin/racket: bad switch: --cross-compiler
Use the --help or -h flag for help.
 in build-one
 in loop
 in module->hash
make: *** [Makefile:16: install] Error 1
error: in phase 'install': uncaught exception:
%exception #<&invoke-error program: "make" arguments: ("install" "ZUO=/gnu/store/i9h1vc67h9148xvn8djk8j3smlkhaf09-zuo-1.0-racket8.6/bin/zuo") exit-status: 2 term-signal: #f stop-signal: #f> 
phase `install' failed after 26.8 seconds
command "make" "install" "ZUO=/gnu/store/i9h1vc67h9148xvn8djk8j3smlkhaf09-zuo-1.0-racket8.6/bin/zuo" failed with status 2

It looks like the problem might be the assumption in

# For a pb build where Racket is supplied, force cross-build
# mode on the assumption that the host is not a pb build
# (because it should be created with default configure options)
if test "${enable_pb}" = "yes" ; then
  if test "${enable_racket}" != "" ; then
    if test "${enable_target}" = "" ; then

Maybe that check should move before the preceding block that sets MACH, an then add check here that "${MACH}" = ""?

I thought this seemed right, but, when I started looking at changing the code, I was less sure. If the check I pointed to:

moved before the preceding block beginning with if test "${enable_mach}" != "", I think the result would be the same, because the preceding case "$MACH_HOST_CPU" statement sets MACH="" for powerpc64*, and the value from --enable-mach=tpb64l won't have been consulted yet.

Tangentially, I think:

    # MACH="${thread_prefix}ppc64${MACH_OS}"

is wrong. POWER8 and POWER9 chips can be run in either big-endian or little-endian mode: config.sub normalizes them as e.g. powerpc64-unknown-linux-gnu and powerpc64le-unknown-linux-gnu. IIUC, this is set in the firmware or something: a given operating system runs in big-endian or little-endian mode, not both, so Debian has ports for both ppc64 (big-endian) and ppc64el (little-endian). (Guix only supports little-endian mode.)

More generally, I think it would be better to use the standard Autoconf macros AC_C_BIGENDIAN and AC_CHECK_SIZEOF rather than having to explicitly recognize architecture and os names.

As I looked around more, it seems there's a related assumption in this block slightly later in the file:

if test "${enable_racket}" != "" ; then
  if test "${enable_racket}" != "auto" ; then
  # In non-cross mode, we interpret `--enable-racket` to supply a
  # Racket used only for generating Chez Scheme boot files
  if test "${CROSS_MODE}" = "cross" ; then
  elif test "${enable_racket}" != "auto" ; then

Until now, Guix has been configureing our racket-vm-cs package with both --enable-racket and --enable-scheme. The intention was that the provided scheme would be used to generate the bootfiles and racket (CS when cross-compiling, 3M otherwise) would be used for other purposes: in particular, because Guix policy takes an especially firm stance on bootstrapping, we want to be able to schemify the regexp, io, and thread layers. However, it seems we were not actually doing that yet, so, as I workaround, I tried not providing --enable-racket for non-cross builds: it didn't break existing builds, and I've asked Thiago to try it on hardware.

For a different approach, could we just delete this block?

If I'm following correctly, it seems like it's meant to handle a "cross" build for the current system, but for a pb or pbarch machine type: is there another way to handle that case?

For now, I pushed a change that I think fixes the immediate problem. I'd rather not just delete the troublesome block, because its there to help with building pb much more quickly on a machine where a native build is supported.

I agree that using AC_C_BIGENDIAN and AC_CHECK_SIZEOF would be better.

Thiago tried building with a cherry-picked 70e484e885637c495be5481983dae2207fdd67bb and reports that:

For some reason I didn't understand, the problem I first reported
about rktboot/main.rkt failing during the build of
chez-scheme-for-racket-bootstrap-bootfiles came back. I had to increase
STACK_SAFETY_MARGIN again. I simply increased it 10x to make sure it
would work. If you want I can experiment with different values to find
an appropriate one.

So, as you suggested in:

it seems like there's still some underlying problem. I don't think I know enough about BC internals to have any useful ideas.

For now, unless you have a better idea, I'll propose using the 10x larger STACK_SAFETY_MARGIN for Guix and hope that works well enough to bootstrap CS. Whatever the problem with BC on ppc64le is, I expect it would also be triggered by other Racket programs, so Guix using CS by default on all platforms still seems like an improvement.