[bug#47180] [PATCH] gnu: racket: Don't inject store paths into Racket files.

[Ludovic Courtès]

Hi Philip,

Philip McGrath <philip@philipmcgrath.com> skribis:

> So there seem to be at least three bad cases:
>
>  1. The grafter can mangle .zo files so that Racket can't
>     read them at all.
>  2. The grafter can miss store references in .zo files, so Racket could
>     end up using the ungrafted versions.
>  3. With a garbage collection, Racket could try to use the ungrafted
>     versions but fail to find them at runtime.

Yes, similar to the problems observed with SBCL:

  https://issues.guix.gnu.org/33848

>> Would it be an option to instead turn off compression and keep doing
>> things as usual?
>
> In theory, this should be possible. I see two significant downsides:
>
>  1. Compiled code would be much larger—maybe twice as big—and, if I
>     recall correctly, load times would be worse, too. With the move to
>     Racket CS, existing Racket code moved from a world of small and
>     cheap bytecode to a world of machine code: the default compression
>     settings have been tuned to avoid an unacceptable worsening of
>     binary size and load time.

Interesting (I’m curious how load time can be improved by (1) reading
files in memory instead of merely mmap’ing, and (2) decompressing.)

[...]

> More broadly, I think the best strategy for Racket packaging will be,
> as much as possible, to use Racket's supported configuration features 
> rather than Guix-specific hacks. This seems especially viable since
> Racket has been willing to accept unobtrusive patches upstream that
> help things go smoothly for Guix, e.g. with 8.1 we should no longer
> need any patches to the build scripts: we're all friendly,
> parentheses-loving folks.

That makes sense to me, I’m all for uniting with parentheses-loving
folks of the world.  :-)

> For another example, it looks like existing
> "racket-store-checksum-override.patch" fixes a previous issue
> discussed in <https://issues.guix.gnu.org/30680> caused by grafting zo
> files: I hope this change will also let us remove that patch, though
> I'd want to test more before proposing we drop it. So these problems
> aren't fundamentally new; they just have an additional symptom since
> the change to Racket CS by default in Racket 8.0. If we can fix the
> root problem of violating Racket's assumptions by patching zo files,
> we should be able to stop hunting down symptoms.

OK.

I’m testing v2 of the patch and will push shortly if everything goes
well.

> Rather than using "config.rktd", an alternative approach would be to
> set things up so that `dlopen` would find the foreign libraries,
> perhaps via `LD_LIBRARY_PATH`. This has some intriguing possibilities:
> I could imagine Guix providing an alternate `dlopen` implementation
> that might be useful beyond Racket.

What would that alternate dlopen do?  It still has to know where to look
for things, somehow.

> Nix apparently configures some things via `LD_LIBRARY_PATH`, but their
> approach (as I understand it) relies on generating Racket scripts
> around all Racket-generated executable, which causes other
> problems. There should be workarounds, but it seems better to avoid
> going down that road if we can.

Yeah, as a rule of thumb I’d say: don’t fiddle with LD_LIBRARY_PATH.

> Finally, here's a sketch of how `guix import racket` and such might
> work. Racket's package system has a concept of "package scope", so
> that "installation" scope can coexist with narrower scopes (mostly
> per-user scope, though there are more complex possibilities). Right
> now, Guix puts installation scope in the read-only store, which
> basically corresponds to how other package managers put it in
> root-owned places, except Guix can't write to the store to install
> additional packages. I'm still at the information-gathering stage, but
> my current thinking is that the hypothetical `racket-build-system`
> should basically take the source package and turn it into what Racket
> calls a "built" package ready to be installed in `static-link` mode,
> which includes compiling the code and building the docs (which can
> involve quite a lot, e.g. ray tracing icons). Then a profile hook
> could knit together all of the Racket packages into an installation
> package scope. For packages that depend on foreign libraries, this
> would be a chance for Guix to add the necessary paths to the
> "config.rktd" for the installation.

I’m not sure I follow the details and I’m glad you have a plan.
Finally having a Racket importer would be sweet!

Thanks!

Ludo’.