[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[bug#49565] [PATCH] gnu: glibc-headers-mesboot: Use %build-inputs in set
[bug#49565] [PATCH] gnu: glibc-headers-mesboot: Use %build-inputs in setenv phase
Thu, 15 Jul 2021 14:58:54 +0200
Thiago Jung Bauermann via Guix-patches via schreef op wo 14-07-2021 om 21:46
> When cross-building from x86-64-linux to powerpc64le-linux,
> (assoc-ref inputs "libc") returns #f so get it from %build-inputs
> 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 \
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)
(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
> 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"))
Description: This is a digitally signed message part