guix-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug#49565] [PATCH] gnu: glibc-headers-mesboot: Use %build-inputs in set


From: Maxime Devos
Subject: [bug#49565] [PATCH] gnu: glibc-headers-mesboot: Use %build-inputs in setenv phase
Date: Thu, 15 Jul 2021 14:58:54 +0200
User-agent: Evolution 3.34.2

Hi,

Thiago Jung Bauermann via Guix-patches via schreef op wo 14-07-2021 om 21:46 
[-0300]:
> When cross-building from x86-64-linux to powerpc64le-linux,
> (assoc-ref inputs "libc") returns #f so get it from %build-inputs
> instead.
> 
> For consistency, do the same for the other inputs as well.
> 
> * gnu/packages/commencement.scm (glibc-headers-mesboot)[arguments]: Get
> packages from ‘%build-inputs’ rather than ‘inputs’.
> ---
>  gnu/packages/commencement.scm | 8 ++++----
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> When running
> 
> ```
> $ ./pre-inst-env guix build \
>       --target=powerpc64le-linux-gnu.gcc \
>       gcc-toolchain@11
> ```

To be clear: are you trying to cross-compile GCC
(that will be run on powerpc64le and produce binaries
for powerpc64le) or are you trying to build a cross-compiler
(that will be run on x86_64 and produce binaries for powerpc64le)?

This command does the former.

> on current core-updates branch (commit 8456581375cf), I get the
> following error during the build of glibc-mesboot-2.16:

Why is 'glibc-mesboot-2.16' being cross-compiled here?
Mesboot currently only supported i686-linux and x86_64-linux and
not powerpc64le-linux (at least the version currently in Guix).

> I deduced that this is because `(assoc-ref inputs "libc")` is returning #f.
> And indeed, changing the code to look in %build-inputs instead fixes the
> issue. I also noticed that most other places which look for a "libc"
> package do so in %build-inputs rather than in inputs.
> 
> Just changing the line for "libc" is enough to fix the build but for
> consistency, also change the other variables as well.

Normally, looking up inputs in 'inputs' is the right thing,
but 'libc' is special. Looking at 'standard-cross-packages',
it seems like when cross-compiling, "libc" is renamed to "cross-libc",
for no apparent reason.  Maybe it can be renamed back to "libc"?

That could simplify some code, e.g. in qtbase-5:

             (let ((glibc (assoc-ref inputs ,(if (%current-target-system)
                                                 "cross-libc" "libc"))))

would become:

             (let ((glibc (assoc-ref inputs "cross-libc")))

If I search with git grep '"cross-libc" "libc", I find 5 such examples.

Are you sure your usage of (assoc-ref %build-inputs "libc") is correct here?
As "libc" currently doesn't exist in 'inputs', that means "libc" is searched
for in 'native-inputs', which is probably not what you want, given that you
are cross-compiling?

> diff --git a/gnu/packages/commencement.scm b/gnu/packages/commencement.scm
> index fb028390a260..ab22bca2fb8f 100644
> --- a/gnu/packages/commencement.scm
> +++ b/gnu/packages/commencement.scm
> @@ -2133,10 +2133,10 @@ ac_cv_c_float_format='IEEE (little-endian)'
>                 (invoke "tar" "xvf" source)
>                 (chdir (string-append "glibc-" ,version))))
>             (replace 'setenv
> -             (lambda* (#:key inputs #:allow-other-keys)
> -               (let* ((headers  (assoc-ref inputs "headers"))
> -                      (libc     (assoc-ref inputs "libc"))
> -                      (gcc      (assoc-ref inputs "gcc"))
> +             (lambda _
> +               (let* ((headers  (assoc-ref %build-inputs "headers"))
> +                      (libc     (assoc-ref %build-inputs "libc"))
> +                      (gcc      (assoc-ref %build-inputs "gcc"))
>                        (cppflags (string-append
>                                   " -I " (getcwd) "/nptl/sysdeps/pthread/bits"
>                                   " -D BOOTSTRAP_GLIBC=1"))

Greetings,
Maxime.

Attachment: signature.asc
Description: This is a digitally signed message part


reply via email to

[Prev in Thread] Current Thread [Next in Thread]