Hi Mark,
The bug stems from ‘ld-wrapper-boot0’ and was introduced in
d75acc293dd3e63db8739aa04c021df917aa1b80. The problem is that
‘ld-wrapper-boot0’ uses the value of (%current-system) on the machine
that builds the derivation—i.e., hydra.gnu.org.
Instead, it should use the value of the system we’re building for, so
its evaluation should be delayed, as is the case for ‘inputs’ fields.
The result of this bug is that ‘ld-wrapper-boot0’ is bogus on all arches
except x86_64. However, this is harmless: we don’t need this ld wrapper
anyway, except for GNU/Hurd.
So, a short-term hack might be this:
diff --git a/gnu/packages/commencement.scm b/gnu/packages/commencement.scm
index 53ba718..0a8e608 100644
--- a/gnu/packages/commencement.scm
+++ b/gnu/packages/commencement.scm
@@ -424,8 +424,8 @@ the bootstrap environment."
(define ld-wrapper-boot0
;; We need this so binaries on Hurd will have libmachuser and libhurduser
;; in their RUNPATH, otherwise validate-runpath will fail.
- (make-ld-wrapper (string-append "ld-wrapper-" (boot-triplet))
- #:target (boot-triplet)
+ (make-ld-wrapper (string-append "ld-wrapper-" "x86_64-guix-linux-gnu")
+ #:target "x86_64-guix-linux-gnu"
#:binutils binutils-boot0
#:guile %bootstrap-guile
#:bash (car (assoc-ref %boot0-inputs "bash"))))
That way, we would not have to rebuild anything (it temporarily breaks
GNU/Hurd though, but that’s the cost we’d have to pay.)
How does that sound?
The actual fix, for the next core-updates cycle, would be to delay
evaluation of ld-wrapper-boot0.
I guess this bug shows that nobody tried to get substitutes for
core-updates on non-x86_64 platforms. :-/
Thanks a lot for the heads-up!
Ludo’.
