Re: rfh: mingw guile.exe stalled by impact of 28dc10a4

[ludo@gnu.org (Ludovic Courtès)]

Hello!

Jan Nieuwenhuizen <janneke@gnu.org> skribis:

> Since then I got somewhat closer but still do not understand what's
> going on.  When I revert
>
>     commit 28dc10a455689c807abc9241ed1094d902a9d9fa
>     Author: Ludovic Courtès <ludo@gnu.org>
>     Date:   Sun May 29 23:15:14 2016 +0200
>
>         gnu: glibc: Refer to the target kernel headers when cross-compiling.
>
>     ...
>
>     diff --git a/gnu/packages/base.scm b/gnu/packages/base.scm
>     index beb689e..b5e229e 100644
>     --- a/gnu/packages/base.scm
>     +++ b/gnu/packages/base.scm
>     @@ -532,7 +532,10 @@ store.")
>                                 ,version)
>
>                  (string-append "--with-headers="
>     -                           (assoc-ref %build-inputs "linux-headers")
>     +                           (assoc-ref ,(if (%current-target-system)
>     +                                           '%build-target-inputs
>     +                                           '%build-inputs)
>     +                                      "linux-headers")
>                                 "/include")
>
>                  ;; This is the default for most architectures as of GNU libc 2.21,
>
> then readline (and guile) can be cross-built for mingw.
>
> However, with this commit present, when cross building readline on my v9
> branch (https://gitlab.com/janneke/guix) like so:
>
>     ./pre-inst-env guix build --target=i686-w64-mingw32 readline
>
> this now triggers the build of gcc-cross-sans-libc-x86_64-linux-gnu
> and gcc-x86_64-linux-gnu.

Hmm the above commit normally cannot trigger anything since it simply
modifies “build-side” code (that is, it does not change the inputs of
packages; it just changes the content of the build program.)

Are you sure that reverting this commit solves the problem?

Maybe we’re entering a cross-build context with ‘%current-target-system’
set to ‘x86_64-linux-gnu’ at some point?

Ludo’.