Hi,
Ludovic Courtès <l...@gnu.org> skribis:
> I’ve tried to address it in an API-compatible way, which meant setting
> the ‘%current-system’ and ‘%current-target-system’ parameters around the
> hook calls, but that is ugly, hard to get right (dynamic binding and
> monadic code really don’t go together well :-/), and actually raises
> another issue (‘mapm/accumulate-builds’ appears to ignore the initial
> dynamic bindings for these two parameters). Hacky patch attached to
> illustrate.
I was able to boil this second sub-problem down to a simple case:
--8<---------------cut here---------------start------------->8---
$ cat /tmp/t.scm
(use-modules (guix)
(guix grafts)
(gnu packages idutils))
(define target
(getenv "REAL_TARGET"))
(%graft? #f)
(with-store s
(parameterize ((%current-target-system (getenv "TARGET")))
(pk (if target
(package-cross-derivation s idutils target)
(package-derivation s idutils)))))
$ REAL_TARGET=arm-linux-gnueabihf ./pre-inst-env guile /tmp/t.scm
;;; (#<derivation /gnu/store/1y5rjcvs6giag414wg4ngz7cp4mxy76v-idutils-4.6.drv
=> /gnu/store/6kq4ick0jljrfjnhw0v2yghr8nalhrqi-idutils-4.6 7f0867c0de10>)
$ TARGET=arm-linux-gnueabihf REAL_TARGET=arm-linux-gnueabihf ./pre-inst-env
guile /tmp/t.scm
;;; (#<derivation /gnu/store/4k4nqr1rpm07ypq9inhvsghrqma5yacy-idutils-4.6.drv
=> /gnu/store/v4rgm5yhyx5ir3622hhxcaz3a10flcyr-idutils-4.6 7f7a4b1010a0>)
--8<---------------cut here---------------end--------------->8---
IOW, the initial value of ‘%current-target-system’ leads us to pick
ld-wrapper -> guile -> bdw-gc -> libatomic-ops in the second case, which
is wrong and due to this conditional in libgc’s inputs:
(propagated-inputs
(if (%current-target-system)
;; The build system refuses to check for compiler intrinsics when
;; cross-compiling, and demands using libatomic-ops instead.
`(("libatomic-ops" ,libatomic-ops))
'()))
As it turns out, ‘guix pack’ and ‘guix system’ are the only programs
that set ‘%current-target-system’ at the top level, via
‘run-with-store’.
Ludo’.
