Re: bug#30680: [racket-users] Using Racket's raco on on Guix(SD)

[Timothy Sample <samplet@ngyro.com>]

Christopher Lemmer Webber <cwebber@dustycloud.org> writes:

> Konrad Hinsen writes:
>
>> In my tests, all packages ended up working, but performance is indeed
>> worse than with a Racket installation outside of Guix.
>>
>> It would be nice if someone with more knowledge of Racket internals
>> could give a hint or two for debugging this issue!
>>
>> Konrad.
>
> I'm posting a bug bounty on this issue: if someone can fix this I will
> pay them $250 USD.  I don't have the time or knowledge enough of Racket
> internals to do so myself.

I have discovered a few things, but I’m not sure how to fix the
underlying problem(s).

The reason Racket is trying to recompile the OpenSSL files is because of
a hash mismatch.  This can be seen by enabling debugging output:

    $ PLTSTDERR=debug raco setup openssl

Which says a lot of things, but most interestingly it says:

--------------------------------
...
compiler/cm: checking: /gnu/store/jx0bkmaafb8fq0mqs5ywgnxq8rbpn8j1-racket-6.12/share/racket/collects/openssl/libcrypto.rkt
compiler/cm: different src hash... (5d9ca57f3e267d956c7b5e62578467beb8ccc1d2 4d21ac412723fbf33f97669c2f73f0e9367f4510)
compiler/cm: maybe-compile-zo starting /gnu/store/jx0bkmaafb8fq0mqs5ywgnxq8rbpn8j1-racket-6.12/share/racket/collects/openssl/libcrypto.rkt
compiler/cm:   start-compile: /gnu/store/jx0bkmaafb8fq0mqs5ywgnxq8rbpn8j1-racket-6.12/share/racket/collects/openssl/libcrypto.rkt
compiler/cm:   compiling /gnu/store/jx0bkmaafb8fq0mqs5ywgnxq8rbpn8j1-racket-6.12/share/racket/collects/openssl/libcrypto.rkt
open-output-file: cannot open output file
  path: /gnu/store/jx0bkmaafb8fq0mqs5ywgnxq8rbpn8j1-racket-6.12/share/racket/collects/openssl/compiled/tmp15340167971534016797570
  system error: Read-only file system; errno=30
  context...:
...
--------------------------------

This hash mismatch is caused by grafting.  When the package is built,
the path to OpenSSL gets hard-coded in a source file.  The SHA-1 hash
for this file is stored in its “.dep” file.  When the output is grafted,
the source file gets updated with a new OpenSSL path, but the hash does
not get updated.  This makes Racket think that the cached bytecode file
is incorrect (even though it was likely grafted too), and it tries to
recompile it.  It fails because it tries to write this new bytecode file
to the store.

I double checked this by trying with an ungrafted Racket, and got better
results.  (There was still a warning about writing to the store, but it
seemed less significant.)

The only thing I can think of for a fix would be to patch Racket to be
more lenient with bytecode files in the store.  That is, ignore hash
mismatches in store-files.  I might give this a try later tonight if
nobody has any better ideas.


-- Tim