Closed sschwarzer closed 1 year ago
By the way, when the fasl-read
error is raised, would it be possible to output which file (path) led to the bytevector? I guess this might help with debugging such problems.
It looks like this is a problem with raco exe
in cross-compile mode. Unfortunately, that means it can't be fixed in just raco cross
, but has to be fixed in the distributon.
I've pushed a repair for the next snapshot. Meanwhile, the best workaround is probably to use raco make
before raco exe
.
@mflatt , thanks for the feedback.
Meanwhile, the best workaround is probably to use raco make before raco exe.
I changed the script to
#! /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
#
raco cross --target x86_64-win32 make games/sudoku-solver.rkt
raco cross --target x86_64-win32 exe --orig-exe --embed-dlls \
-o sudoku-solver.exe games/sudoku-solver.rkt
find . -type d -name compiled | xargs rm -rf
Is that what you meant? I still get the fasl-read
exception on the second run of the script.
I plan to try the Racket version from master
with your fix later today.
That's what I meant. I now see the problem with that workaround, though. Removing compiled
does not remove the host shadow in <workarea>/x86_64-win32-cs/build/zo/
, and raco make
doesn't detect the half-built state. Probably the right additional repair is to improve raco make
in cross-compile mode.
Meanwhile, a further workaround is to remove shadow compiled
directories within <workarea>/x86_64-win32-cs/build/zo/
. Within zo/
, the path is based to a shadow compiled
directory is based on the absolute path to the normal compiled
directory.
racket/racket
(they include your two commits e3087d70 and 00d53ebf),$PATH
to use the development version of the Racket binaries,PATH
change by running which racket
(also, racket --version
now outputs 8.2.0.7 instead of 8.2
)sudoku-solver
working directory andreproduce_issue.sh
(without any raco make
invocations) twice.I still get the fasl-read
error on the second run of reproduce_issue.sh
.
Meanwhile, a further workaround is to remove shadow compiled directories within
/x86_64-win32-cs/build/zo/.
By "workarea", I assume you mean the directory where raco-cross
puts its files, i. e. ~/.local/share/racket/raco-cross/8.2
on my system? (I just see that raco cross
outputs a "Workspace" directory for each run; you probably mean this, right?)
I don't know what a shadow compiled
directory is, but I assume you mean that any compiled
directory under <workarea>/x86_64-win32-cs/build/zo/
is a shadow compiled
directory?
Within zo/, the path is based to a shadow compiled directory is based on the absolute path to the normal compiled directory.
I don't understand this sentence. Is the grammar as you intended?
Regarding the workaround of removing compiled
directories in the workarea: After running reproduce_issue.sh
, I ran
find ~/.local/share/racket/raco-cross/8.2/x86_64-win32-cs/build/zo -name compiled -type d | xargs rm -rf
When I run reproduce_issue.sh
after this, every run of raco cross
fails with the fasl-read
error, not just the raco exe
invocation. I notice the stacktraces are much shorter though:
>> Cross configuration
Target: x86_64-win32
Host: x86_64-linux
Version: 8.2
VM: cs
Workspace: /home/schwa/.local/share/racket/raco-cross/8.2
fasl-read: incompatible fasl-object machine-type 'ta6nt found in #<binary input port bytevector>
context...:
body of data
body of "/home/schwa/.local/share/racket/raco-cross/8.2/x86_64-win32-cs/collects/raco/main.rkt"
raco cross: command failed
As far as I can tell, I get exactly this same output four times.
Unfortunately, since the problem is in the distribution, then it won't help to use a newer Racket to run raco cross
. Instead, you'd need to use a snapshot build (https://docs.racket-lang.org/raco-cross/index.html#%28part._snapshots%29) in place of v8.2. Doing things with compiled
and raco exe ... make
is an alternative to using a snapshot build.
Meanwhile, ~/.local/share/racket/raco-cross/8.2/x86_64-win32-cs/build/zo
is not quite the directory I was trying to refer to. By removing all compiled
directories within the zo
directory, it's as if raco setup
has never been run for the cross installation, and that will indeed make raco cross ... exe
fail even more with v8.2. You can use raco cross --target x86_64-win32 setup
to get the cross installation back into reasonable shape. (Unless I'm forgetting yet another thing.)
Then:
The suggestion was meant to be to remove only the part under the zo
that corresponds to your sudoku-solver
checkout. So, if sudoku-solver
is checked out as ~/example/sudoku-solver
, then remove ~/.local/share/racket/raco-cross/8.2/x86_64-win32-cs/build/zo/home/schwa/example/sudoku-solver
.
Even so, removing that directory won't make raco cross ... exe
work. It was intended as a way of making raco cross ... make games/sudoku-solver.rkt
work.
After raco cross ... make
works, then raco cross ... exe
should be able to work.
Maybe the better strategy is to use a snapshot instead of v8.2, and then you don't need to adjust zo
or compiled
directories to work around problems in the distribution.
Or, here's one more workaround — probably the easiest, but also the slowest: Remove the cross installation with raco cross --target x86_64-win32 --remove
to start fresh every time you want to rebuild By starting with a fresh cross installation, you avoid any mismatched state from old/removed compiled
directories.
Unfortunately, since the problem is in the distribution, then it won't help to use a newer Racket to run raco cross.
That was surprising. I hadn't thought it would make a difference if I recompiled the Racket binaries.
Instead, you'd need to use a snapshot build (https://docs.racket-lang.org/raco-cross/index.html#%28part._snapshots%29) in place of v8.2.
From the link I conclude that with "snapshot" (aka "distribution"?) you weren't referring to a new version of the host system (as I thought), but different snapshots to be installed by raco cross. Is this correct now? :-) If yes, this would mean, if I'm not mistaken, that the cross compilation problem with raco exe
will only be "properly" fixed when Racket 8.3 comes out because then raco cross will by default use the Racket 8.3 snapshots which contain the fix.
Or, here's one more workaround — probably the easiest, but also the slowest: Remove the cross installation with raco cross --target x86_64-win32 --remove to start fresh every time you want to rebuild
I guess I'm going with this for now instead of fiddling with the right compiled
directories or snapshots. :-)
My workaround so far was to remove the whole workspace. Selectively removing the target with --remove
seems to work indeed, from what I have just tried, so this saves at least the time for creating the other directories in the workspace (although it's not a big difference).
As far as I'm concerned, you can close this ticket if you're sure your changes to https://github.com/racket/racket/ fix the problem. Personally, I'd leave the ticket open until Racket 8.3 is released because people coming here with the problem of this ticket are (I think) more likely to look at an open ticket than a closed ticket if they use an up-to-date version of raco cross
.
On the other hand, you could argue that this ticket only exists because of a bug in Racket, not raco cross, so there's nothing to fix here anyway. :-D
Closing, since this issue has been fixed in releases for a while now.
The error message is the same as for https://github.com/racket/raco-cross/issues/3 and https://github.com/mflatt/raco-cross/issues/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 https://github.com/racket/raco-cross/commit/79de8356d20ec79b4fed58c32f4ab45dbfbf485c 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,The Windows binary is created as expected. However, if the line
find . -type d -name compiled | xargs rm -rf
is commented out, theraco cross exe
invocation after that line fails withIf the
find ...
command is not commented out, the next run ofreproduce_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 nativeraco exe -o sudoku-solver-linux games/sudoku-solver.rkt
(when the dependencies are installed) without needing the files undercompiled
.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.