Closed samth closed 2 years ago
Just -R
works correctly.
It looks like the issue is that cross-build mode (as triggered by -MCR
) performs an executable-relative directory lookup that isn't cached in the same way as the non-cross directories. I can add caching.
Caching feels odd as a fix here. If the code doesn't have permission to do this operation, then why is it ok to get the results of it from a cache?
Finding the collects
directory means a search starting with the name used to launch Racket, possibly using the PATH
environment variable and inspecting those directories, possibly following soft links, and all the while appending a multi-element relative path to check whether we've found it, yet. It's a complex search and can touch a lot of things, but the end result is simple — typically some path right next to the executable. The intent is that this end path is accessible within a sandbox, but not necessarily everything that goes into finding that directory.
You may wonder why the implementation doesn't just compute the path at startup time and record it, as opposed to "caching" sometime later. There's an interplay of things written in Racket and built into the kernel, and this "caching" approach is the way I found to do it once upon a time. The exact mechanism might be a little different starting from scratch (now that it's easier to write startup tasks in Racket). But the underlying problem and repair would be about the same: a cross-compilation path would need to be computed and registered in addition to the two paths already registered.
Currently the
rival
package has the following error when run on https://pkg-build.racket-lang.org (saved at archived):To reproduce (on my machine, with a regular install of Racket, more details below):