Hi Jakub, Jakub Kądziołka writes: > On Sun, Aug 16, 2020 at 03:42:38PM +0100, Pierre Langlois wrote: >> >> Pierre Langlois writes: >> >> > Hello Guix! >> > >> > In an optimistic attempt to eventually have Icecat on a Pinebook Pro, I >> > thought I'd try and get rust building on aarch64. Here's a fix for the >> > post-install phase that had an x86 triplet hardcoded. With this we're >> > able to start off the bootstrap chain! >> > >> > That being said, each step takes ~5 hours on this machine so this is >> > going to take a while :-), it's currently working on 1.23. >> > >> > So, I suppose this should go into either core-updates or staging? WDYT? >> >> Whoops, I forgot the copyright line on that file. >> > > Pierre, > > thanks for your patch! I was working on a similar change before, but > when I tried it, it failed even earlier in the bootstrap chain. It > might've been QEMU weirdness, though, a la #42448. > >> @@ -612,9 +613,10 @@ jemalloc = \"" jemalloc "/lib/libjemalloc_pic.a" "\" >> (cargo-out (assoc-ref outputs "cargo"))) >> (for-each >> (lambda (file) (delete-manifest-file out file)) >> - '("install.log" >> + `("install.log" >> "manifest-rust-docs" >> - "manifest-rust-std-x86_64-unknown-linux-gnu" >> + ,,(string-append "manifest-rust-std-" >> + (nix-system->gnu-triplet-for-rust)) >> "manifest-rustc")) >> (for-each >> (lambda (file) (delete-manifest-file cargo-out file)) > > If I understand the code correctly, this quasiquote is unnecessary, as > the host-side code will evaluate to a string that can be inserted as-is, > without another unquote on the build side. > > Fixing this would mean that the patch can go on master, since it would > now only trigger rebuilds on architectures that are already broken. Ooooh yeah, that'll be much better, I've attached a patch that does just that. I can confirm it doesn't trigger a full rebuild, nice! > I wish you best of luck on your quest for Rust on ARM boards. This has > been a long-standing issue, and it'd be nice to have it fixed. Let me > know if you need any help - I packaged the last few versions, so I got > quite familiar with the various failure modes of the build process. I'm > NieDzejkob on IRC, if you prefer. haha, thanks :-), I haven't got very far with it yet, the build failed at 1.23 with a test case failure. Something to do with receiving the wrong signal on an expected crash. I'm optimistic though! I don't have the build log around anymore, but we can see if the CI has the same problem. I haven't spent much time investigating, instead thinking I'm better off trying to get the patches that allow bootstrapping from 1.29 working. I was planning on looking into that. Otherwise we can skip any tests that don't pass and carry on, I suspect it's normal behaviour on that platform and the tests need updating. I think aarch64 is officially supported now but it's probably quite recent. Thanks, Pierre