Hi!

Jan Nieuwenhuizen <janneke@gnu.org> skribis:

> With static-bash-for-glibc, however, it goes off track
>
> $ ./pre-inst-env guix build --system=i586-gnu \
>    -e '(@@ (gnu packages commencement) static-bash-for-glibc)'
> The following derivations will be built:
>    /gnu/store/gv40jpz4g0hbia28wa6d50z9x6ncgdlh-bash-static-5.0.16.drv
>    /gnu/store/apj2ihazv6x3anhvfvmmqrkyak05p9yc-gcc-cross-boot0-wrapped-7.5.0.drv
>    /gnu/store/yfpy5b3xqkarxchyhi339fw2ldwczj1d-linux-libre-headers-5.4.20.drv
>
>
> ...oops!  Note that a native build on the Childhurd works all the way up
> to "hello".
>
> The "glibc-final-with-bootstrap-bash" has a propagated-inputs that looks
> like this
>
> (define* (kernel-headers-boot0 #:optional (system (%current-system)))
>   (match system
>     ("i586-gnu" hurd-core-headers-boot0)
>     (_ linux-libre-headers-boot0)))
>
> (define glibc-final-with-bootstrap-bash
>    [..]
>    (propagated-inputs `(("kernel-headers" ,(kernel-headers-boot0))))
>    [..])
>
> In KERNEL-HEADERS-BOOT0, SYSTEM is "x86_64-linux".  Passing SYSTEM from
> a LET-SYSTEM clause (see attached patch) seems to fix this...but i'm
> afraid that triggers a world rebuild.  Our offload Childhurds can only
> run master, right?  Is there any way around this?  Thoughts?

Here’s my powerful debugging trick for such dynamic binding issues (it’s
not related to offloading):