The error message is the same as for #3 and mflatt/raco-cross#3 , but this issue seems to be different.
The host system is Fedora Linux 34 with Racket 8.2 cs and the newest version of raco cross
. (I even checked in the source code, if the change 79de835 is present.) Also, the Racket installation is set to use installation scope anyway.
I tried to narrow down the problem, but I still need my project directory from https://git.sr.ht/~sschwarzer/sudoku-solver . On the other hand, at least you don't need the makefile. :-)
Now, if I clone my repo, remove ~/.local/share/racket/raco-cross/8.2
and run this script,
$ cat reproduce_issue.sh
#! /bin/sh
# Compiled files cause trouble if they were compiled for a different target/VM.
find . -type d -name compiled | xargs rm -rf
# Ignore uninstalled package.
raco cross --target x86_64-win32 pkg remove sudoku-solver || true
# Implicitly install dependencies.
raco cross --target x86_64-win32 pkg install --deps search-auto
raco cross --target x86_64-win32 pkg remove sudoku-solver
# If the `compiled` directories are deleted here, the `raco cross exe`
# invocation fails with
# fasl-read: incompatible fasl-object machine-type 'ta6nt found in #<binary input port bytevector>
#
# If the `compiled` directories are left alone _here_, the
# `raco cross exe` invocation generates the binary, but the _next_
# run of `reproduce_issue.sh` fails with the `fasl-read` exception.
#
# find . -type d -name compiled | xargs rm -rf
raco cross --target x86_64-win32 exe --orig-exe --embed-dlls \
-o sudoku-solver.exe games/sudoku-solver.rkt
The Windows binary is created as expected. However, if the line find . -type d -name compiled | xargs rm -rf
is commented out, the raco cross exe
invocation after that line fails with
fasl-read: incompatible fasl-object machine-type 'ta6nt found in #<binary input port bytevector>
context...:
body of syntax-literals
/home/schwa/.local/share/racket/raco-cross/8.2/x86_64-win32-cs/collects/compiler/embed.rkt:445:0: get-code
[repeats 1 more time]
/home/schwa/.local/share/racket/raco-cross/8.2/x86_64-win32-cs/collects/racket/private/map.rkt:267:2: gen-for-each
/home/schwa/.local/share/racket/raco-cross/8.2/x86_64-win32-cs/collects/compiler/embed.rkt:1178:0: do-write-module-bundle
/home/schwa/.local/share/racket/raco-cross/8.2/x86_64-win32-cs/collects/compiler/embed.rkt:1658:15: write-module
/home/schwa/.local/share/racket/raco-cross/8.2/x86_64-win32-cs/collects/compiler/embed.rkt:1562:6
/home/schwa/.local/share/racket/raco-cross/8.2/x86_64-win32-cs/share/pkgs/compiler-lib/compiler/commands/exe.rkt:100:0
body of "/home/schwa/.local/share/racket/raco-cross/8.2/x86_64-win32-cs/share/pkgs/compiler-lib/compiler/commands/exe.rkt"
/home/schwa/.local/share/racket/raco-cross/8.2/x86_64-win32-cs/collects/raco/raco.rkt:41:0
body of "/home/schwa/.local/share/racket/raco-cross/8.2/x86_64-win32-cs/collects/raco/raco.rkt"
body of "/home/schwa/.local/share/racket/raco-cross/8.2/x86_64-win32-cs/collects/raco/main.rkt"
raco cross: command failed
If the find ...
command is not commented out, the next run of reproduce_issue.sh
fails with the same stacktrace. The only workaround I've found is to remove ~/.local/share/racket/raco-cross/8.2
and then re-run the script (or rather the equivalent section from the Makefile).
I've tried for hours to find out what happens here, without success. It's really strange (to me) why the files under the compiled
directories should be needed even after the package is removed. After all, I can run a native raco exe -o sudoku-solver-linux games/sudoku-solver.rkt
(when the dependencies are installed) without needing the files under compiled
.
Ideally, I'd be interested in an explanation what's going on, but I'd also be relatively content with a suggestion of a workaround that doesn't require to remove and bootstrap the target installation for each compilation. Of course, if this can be fixed in raco cross
or possibly Racket, this would be even better. By the way, I'm rather sure the Makefile used to work previously, so I wonder if there's possibly a change from Racket 8.1 to 8.2 that triggers the problem.