[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[bug#47180] [PATCH] gnu: racket: Don't inject store paths into Racket fi
[bug#47180] [PATCH] gnu: racket: Don't inject store paths into Racket files.
Mon, 12 Apr 2021 14:55:06 +0200
Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux)
Philip McGrath <email@example.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:
>> 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.
I’m testing v2 of the patch and will push shortly if everything goes
> 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!