Christopher Lemmer Webber <cweb...@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