./contrib/guix/guix-build does not work on riscv64 #29020

Steps to reproduce:

# dpkg --print-architecture && HOSTS="arm64-apple-darwin" V=1 VERBOSE=1 MAX_JOBS=$(nproc) ./contrib/guix/guix-build 
riscv64
Found macOS SDK at '/bitcoin-core/depends/SDKs/Xcode-12.2-12B45b-extracted-SDK-with-libcxx-headers', using...
Checking that we can connect to the guix-daemon...

Hint: If this hangs, you may want to try turning your guix-daemon off and on
      again.

accepted connection from pid 2870003, user root
make: Entering directory '/bitcoin-core/depends'
make[1]: Entering directory '/bitcoin-core/depends'
make[1]: Leaving directory '/bitcoin-core/depends'
make: Leaving directory '/bitcoin-core/depends'
INFO: Building 92d12f1c8903 for platform triple arm64-apple-darwin:
      ...using reference timestamp: 1696409041
      ...running at most 4 jobs
      ...from worktree directory: '/bitcoin-core'
          ...bind-mounted in container to: '/bitcoin'
      ...in build directory: '/bitcoin-core/guix-build-92d12f1c8903/distsrc-92d12f1c8903-arm64-apple-darwin'
          ...bind-mounted in container to: '/distsrc-base/distsrc-92d12f1c8903-arm64-apple-darwin'
      ...outputting in: '/bitcoin-core/guix-build-92d12f1c8903/output/arm64-apple-darwin'
          ...bind-mounted in container to: '/outdir-base/arm64-apple-darwin'
accepted connection from pid 2872281, user root
accepted connection from pid 2872281, user root
Backtrace:
          18 (primitive-load "/root/.cache/guix/inferiors/4wrulds2lx?")
In guix/ui.scm:
   2324:7 17 (run-guix . _)
  2287:10 16 (run-guix-command _ . _)
In ice-9/boot-9.scm:
  1752:10 15 (with-exception-handler _ _ #:unwind? _ # _)
In guix/store.scm:
    672:3 14 (guix-environment* _)
In ice-9/boot-9.scm:
  1752:10 13 (with-exception-handler _ _ #:unwind? _ # _)
In guix/store.scm:
   659:37 12 (thunk)
   1298:8 11 (call-with-build-handler _ _)
   1298:8 10 (call-with-build-handler #<procedure 3f812c0ea0 at gui?> ?)
In guix/status.scm:
    839:4  9 (call-with-status-report _ _)
In guix/scripts/environment.scm:
  1158:11  8 (_)
In guix/store.scm:
  2168:25  7 (run-with-store #<store-connection 256.99 3f851f2af0> _ ?)
In guix/scripts/environment.scm:
    869:8  6 (_ _)
In gnu/build/linux-container.scm:
   397:16  5 (call-with-container (#<<file-system> device: "none?> ?) ?)
   239:15  4 (run-container "/tmp/guix-directory.GcTuOV" (#<<fil?> ?) ?)
In guix/build/syscalls.scm:
  1114:21  3 (_ 2114060305)
In unknown file:
Exception thrown while printing backtrace:
In procedure primitive-call-ip: Wrong type argument in position 1 (expecting PRIMITIVE_P): #<procedure 3f82490420 (_ _ _ _ _ _)>

ice-9/boot-9.scm:1685:16: In procedure raise-exception:
Wrong type (expecting exact integer): #f

guix itself seems to be working:

# type rustc && rustc --version 
rustc is hashed (/var/guix/profiles/per-user/root/guix-profile/bin/rustc)
rustc 1.60.0

Is it only the apple cross-compiles that aren't working, or all builds? I assume it's only the apple cross-compiles given that is what is being shown here.

guix itself seems to be working:

What is the Guix version?

The other targets seem to be affected as well. (Tested Windows as well, so far)

The guix version is 1.4, but that shouldn't matter, because of the time-machine.

The guix version is 1.4, but that shouldn't matter, because of the time-machine.

I'm not sure we should make that assumption here. If the version of Guix (1.4), can't properly setup containers on the system (which looks like it could be the issue), and the fixes only landed after 1.4, then builds will still fail. It would be good to get a smaller reproducer of the issue. Does something like guix shell --container --pure some_package work?

# guix shell --container --pure hello 
accepted connection from pid 3269077, user root
Backtrace:
          19 (apply-smob/0 #<thunk 3f887712e0>)
In ice-9/boot-9.scm:
    724:2 18 (call-with-prompt _ _ #<procedure default-prompt-handle?>)
In ice-9/eval.scm:
    619:8 17 (_ #(#(#<directory (guile-user) 3f88776c80>)))
In guix/ui.scm:
   2275:7 16 (run-guix . _)
  2238:10 15 (run-guix-command _ . _)
In ice-9/boot-9.scm:
  1752:10 14 (with-exception-handler _ _ #:unwind? _ # _)
  1752:10 13 (with-exception-handler _ _ #:unwind? _ # _)
In guix/store.scm:
   661:37 12 (thunk)
   1300:8 11 (call-with-build-handler _ _)
   1300:8 10 (call-with-build-handler #<procedure 3f750cc660 at gui?> ?)
In guix/status.scm:
    815:4  9 (call-with-status-report _ _)
In guix/scripts/environment.scm:
  1078:11  8 (_)
In guix/monads.scm:
    576:2  7 (run-with-store #<store-connection 256.99 3f76831730> _ ?)
In guix/scripts/environment.scm:
    793:8  6 (_ _)
In gnu/build/linux-container.scm:
   397:16  5 (call-with-container (#<<file-system> device: "none?> ?) ?)
   239:15  4 (run-container "/tmp/guix-directory.YvLVVm" (#<<fil?> ?) ?)
In guix/build/syscalls.scm:
  1109:21  3 (_ 2114060305)
In unknown file:
Exception thrown while printing backtrace:
In procedure primitive-call-ip: Wrong type argument in position 1 (expecting PRIMITIVE_P): #<procedure 3f85a21fa0 (_ _ _ _ _ _)>

ice-9/boot-9.scm:1685:16: In procedure raise-exception:
Wrong type (expecting exact integer): #f

Ok. So the issue is a bug in Guix. How many weeks will it take to run a guix pull?

Happy to try it, but if that works, then there is a bug in the time-machine, which seems unlikely.

# guix time-machine --commit=77386bdbfe6b0c649c05ab37f08051d1ab3e5074 -- shell --container --pure bash 
accepted connection from pid 3269629, user root
accepted connection from pid 3269629, user root
Backtrace:
          18 (primitive-load "/root/.cache/guix/inferiors/4wrulds2lx?")
In guix/ui.scm:
   2324:7 17 (run-guix . _)
  2287:10 16 (run-guix-command _ . _)
In ice-9/boot-9.scm:
  1752:10 15 (with-exception-handler _ _ #:unwind? _ # _)
In guix/store.scm:
    672:3 14 (guix-environment* _)
In ice-9/boot-9.scm:
  1752:10 13 (with-exception-handler _ _ #:unwind? _ # _)
In guix/store.scm:
   659:37 12 (thunk)
   1298:8 11 (call-with-build-handler _ _)
   1298:8 10 (call-with-build-handler #<procedure 3f80878e40 at gui?> ?)
In guix/status.scm:
    839:4  9 (call-with-status-report _ _)
In guix/scripts/environment.scm:
  1158:11  8 (_)
In guix/store.scm:
  2168:25  7 (run-with-store #<store-connection 256.99 3f84865eb0> # ?)
In guix/scripts/environment.scm:
    869:8  6 (_ _)
In gnu/build/linux-container.scm:
   397:16  5 (call-with-container (#<<file-system> device: "none?> ?) ?)
   239:15  4 (run-container "/tmp/guix-directory.XyJWWq" (#<<fil?> ?) ?)
In guix/build/syscalls.scm:
  1114:21  3 (_ 2114060305)
In unknown file:
Exception thrown while printing backtrace:
In procedure primitive-call-ip: Wrong type argument in position 1 (expecting PRIMITIVE_P): #<procedure 3f81af5480 (_ _ _ _ _ _)>

ice-9/boot-9.scm:1685:16: In procedure raise-exception:
Wrong type (expecting exact integer): #f

then there is a bug in the time-machine, which seems unlikely.

I don't follow. This is failing in the same way, because time-machine is trying to use a container. So it is the same issue.

I mean that guix pull likely won't fix this issue, because if this issue was fixed in a later version of guix, I could simply use the time-machine to run that version of guix. However, that didn't work.

I could simply use the time-machine to run that version of guix

You can't though. Because the guix binary itself, that is trying to run the container, for the time-machine, doesn't have the bug fixes from the future.

Are you sure, because if new guix features are available in the the time-machine, then bug fixes should be as well? (See #26077 (comment))

Looking at the code, it seems more likely that someone forgot to add support for riscv64 somewhere, because the code looks mostly unchanged between 1.4 and master.

https://github.com/guix-mirror/guix/blame/v1.4.0/guix/build/syscalls.scm#L1109 https://github.com/guix-mirror/guix/blame/77386bdbfe6b0c649c05ab37f08051d1ab3e5074/guix/build/syscalls.scm#L1114

Are you sure, because if new guix features are available in the the time-machine, then bug fixes should be as well?

Yea, new Guix features could be compiled/available inside the time-machine, but if you can't even run a time-machine, because your guix 1.4 binary can't launch a container, you are still stuck.

Ah ok. I forgot to clarify, the time-machine itself is working (so far). For example:

# guix time-machine --commit=77386bdbfe6b0c649c05ab37f08051d1ab3e5074 -- shell --pure hello
accepted connection from pid 3274252, user root
hint: Consider passing the `--check' option once to make sure your shell does not clobber environment variables.

# hello
Hello, world!
# exit

Ok, so then this seems to be a bug with just the usage --container, (on riscv64 hardware?) that likely still exists in Guix. We should report the minimal reproducer upstream.

Sure, sent the fix: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=67697

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=67697

Apparently the fix has now landed, but I don't yet see it in https://git.savannah.gnu.org/cgit/guix.git/log/ (or core-updates).

https://git.savannah.gnu.org/cgit/guix.git/commit/?id=d5ca4d4fd713a9f7e17e074a1e37dda99bbb09fc

Guess it's time to guix pull and find the next bug.