[bug#65482] [PATCH 0/3] gnu: racket: Update to 8.10.

[Philip McGrath <philip@philipmcgrath.com>]

Hi,

On 9/8/23 02:12, Efraim Flashner wrote:
>>> build directory: "/tmp/guix-build-chez-scheme-for-racket-9.9.9-pre-release.17.drv-0/source/racket/src/build"
>>> configure flags: ("--disable-x11" "--threads" "-m=trv64le" "--installcsug=/gnu/store/c66pkyb1kvbi0jn1shanxrzbjvfqjmqf-chez-scheme-for-racket-9.9.9-pre-release.17-doc/share/doc/chez-scheme-for-racket-9.9.9-pre-release.17/csug" "--installreleasenotes=/gnu/store/c66pkyb1kvbi0jn1shanxrzbjvfqjmqf-chez-scheme-for-racket-9.9.9-pre-release.17-doc/share/doc/chez-scheme-for-racket-9.9.9-pre-release.17/release_notes" "--installprefix=/gnu/store/bqjwn04ix8xd9bwdni861244yza75qrf-chez-scheme-for-racket-9.9.9-pre-release.17" "ZLIB=-lz" "LZ4=-llz4" "--libkernel" "--nogzip-man-pages")
>>> No suitable machine type found in "../ChezScheme/boot".
>>>
>>> Available machine types:
>>>     tpb64l
>>>
>>> See "../ChezScheme/BUILDING" for ways of getting boot files.
>>>
>>> I'll see about fixing the missing files or configure options. Don't let
>>> it not building on riscv64 delay this update though.
>>>
>>
>> Thanks for this report! I would have expected that to work, and it's tricky
>> to test without hardware.
> 
> Ah, yeah, QEMU is really good but there are definitely times it isn't
> enough, and without real hardware it definitely falls into a "you want
> it, you keep it working" category.
> 

In one of my early attempts to test for ppc64, I thought everything was 
working, but I'd actually just been producing x64 binaries. Then QEMU 
was crashing when running Racket BC, perhaps because of some complicated 
tricks it plays with the stack.

>> Before getting into the weeds, I agree with you that it shouldn't block the
>> update, especially if it was already broken. I'm not a Guix committer, but
>> as far as I'm concerned this series is ready to merge.
>>
>> As far as riscv64, it looks like chez-scheme-for-racket-bootstrap-bootfiles
>> created "portable bytecode" bootfiles ("tpb64l") instead of native riscv64
>> ones. You can confirm if that is the problem (or at least *a* problem) by
>> checking if the lib/chez-scheme-bootfiles directory in the bootstrap
>> package's output contains a directory named "tpb64l" instead of "trv64le".
> 
> That's what I saw when I looked.

Ok, at least it's clear why this state doesn't work, even if still I 
don't know why we fall into this state. (Note the "-m=trv64le" in 
#:configure-flags for chez-scheme-for-racket, which correctly specifies 
that we want the native backend, even though rktboot produced the wrong 
set of bootfiles.

> I've been poking a bunch of packages
> recently so I don't remember exactly, but I think I tried building with
> the tpb64l bytecode and there were some issues later on which made that
> not work.
> 

A tpb64l build is supposed to work, but there are probably some rough 
edges. (In contrast, plain pb and tpb are not enough to be able to run 
Racket.) One thing I remember hearing is that the C compiler tends to 
take a long time on bootfiles compiled from bytecode to C, I guess 
because the C is large and strange-looking. Overall, I think you will 
have a better time getting the native backend to build.

>> If that is indeed the problem, most likely either there is a bug in my
>> change to rktboot's auto-detection or there were additional auto-detection
>> bugs I didn't find.
>>
>> One way things could have gone wrong is if Racket BC returned something
>> unexpected from (system-library-subpath #f). It would help to confirm the
>> results of that, (system-type 'os*), and (system-type 'arch).
>>

Here's a way to test that in one long line:

guix shell -e "(@ (gnu packages racket) racket-vm-bc)" -- sh -c 
"\${GUIX_ENVIRONMENT}/opt/racket-vm/bin/racket -e \"(list (path->string 
(system-library-subpath #f)) (system-type 'arch) (system-type 'os*))\""

On my machine, this prints '("x86_64-linux" x86_64 linux). On riscv64, I 
would expect it to produce '("riscv64-linux" riscv64 linux).

If it produces something else, then my part of 
racket-backport-8.10-rktboot.patch definitely wouldn't work. On the 
other hand, if the result is as expected, then presumably there's some 
other bug elsewhere in rktboot to be patched.

>> In principle, if the problem is only with rktboot's auto-detection, it
>> should work to just keep supplying the explicit --machine flag for now, i.e.
>> drop patch 3/3 from this series.
> 
> I've thought about it both ways, and since all the testing has been with
> the third patch included I'm going to push all three patches and then
> continue working on the riscv64 build.
> 
>> Racket doesn't have CI on riscv64 or distribute builds for it, but Matthew
>> Flatt did share a nice screenshot earlier this summer of DrRacket running on
>> a STAR64 :)
> 
> Patches pushed!
> 

Thanks!

Philip