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

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

[Thiago Jung Bauermann via Guix-patches via]

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
```

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

--8<---------------cut here---------------start------------->8---
phase `setenv' failed after 0.0 seconds
Backtrace:
In ice-9/boot-9.scm:
 157: 15 [catch #t #<catch-closure c93c40> ...]
In unknown file:
   ?: 14 [apply-smob/1 #<catch-closure c93c40>]
In ice-9/boot-9.scm:
  63: 13 [call-with-prompt prompt0 ...]
In ice-9/eval.scm:
 432: 12 [eval # #]
In ice-9/boot-9.scm:
2320: 11 [save-module-excursion #<procedure cc1b00 at
ice-9/boot-9.scm:3961:3 ()>]
3966: 10 [#<procedure cc1b00 at ice-9/boot-9.scm:3961:3 ()>]
1645: 9 [%start-stack load-stack #<procedure cc2ba0 at
ice-9/boot-9.scm:3957:10 ()>]
1650: 8 [#<procedure cc8db0 ()>]
In unknown file:
   ?: 7 [primitive-load
"/gnu/store/7ny6wjvw8pqw1zcgwq8bxja7946l2l2d-glibc-mesboot-2.16.0-builder"]
In ice-9/boot-9.scm:
 157: 6 [catch srfi-34 ...]
In srfi/srfi-1.scm:
 616: 5 [for-each #<procedure 1500040 at
guix/build/gnu-build-system.scm:909:14 (expr)> ...]
In ice-9/boot-9.scm:
 171: 4 [with-throw-handler #t ...]
In guix/build/gnu-build-system.scm:
 925: 3 [#<procedure 14de940 at guix/build/gnu-build-system.scm:924:21
()>]
In ice-9/eval.scm:
 411: 2 [eval # #]
In unknown file:
   ?: 1 [string-append " -L " ...]
In ice-9/boot-9.scm:
 106: 0 [#<procedure 14de900 at ice-9/boot-9.scm:97:6 (thrown-k . args)>
wrong-type-arg ...]

ice-9/boot-9.scm:106:20: In procedure #<procedure 14de900 at
ice-9/boot-9.scm:97:6 (thrown-k . args)>:
ice-9/boot-9.scm:106:20: In procedure string-append: Wrong type
(expecting string): #f
--8<---------------cut here---------------end--------------->8---

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.

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"))

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

[Thiago Jung Bauermann via Guix-patches via]

Em quarta-feira, 14 de julho de 2021, às 21:46:13 -03, Thiago Jung 
Bauermann escreveu:
> When running
> 
> ```
> $ ./pre-inst-env guix build \
> 	--target=powerpc64le-linux-gnu.gcc \
> 	gcc-toolchain@11
> ```

Due to a copy-paste mishap, I used a strange target string above (it has an 
extraneous “.gcc” in the end). I just checked with the following command 
line and I still run into the problem:

```
$ ./pre-inst-env guix build \
	--target=powerpc64le-linux-gnu \
	-e '(@@ (gnu packages commencement) glibc-mesboot)'
```

So the bug report and the patch still stand. :-)

-- 
Thanks,
Thiago

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

[Maxime Devos]

[-- Attachment #1: Type: text/plain, Size: 3692 bytes --]

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 #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 260 bytes --]

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

[Thiago Jung Bauermann via Guix-patches via]

Hello Maxime,

Thanks for your help.

Em quinta-feira, 15 de julho de 2021, às 09:58:54 -03, Maxime Devos 
escreveu:
> 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.

That’s a great question. I hadn’t noticed this subtlety. What I’m actually 
trying to do is reproduce this CI failure on core-updates:

https://ci.guix.gnu.org/build/667452/details

Looking at the log file, I see this:

```
make[2]: Entering directory '/tmp/guix-build-gcc-11.1.0.drv-0/build/gcc'
configure: creating cache ./config.cache
checking build system type... x86_64-unknown-linux-gnu
checking host system type... powerpc64le-unknown-linux-gnu
checking target system type... powerpc64le-unknown-linux-gnu
```

So by luck I’m doing what I needed to do, which is cross-compile a GCC for 
a powerpc64le host and powerpc64le target.

> > 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 don’t know why my system tried to build it. Perhaps because of the bogus 
target string. When I used the correct one I had to use the `guix build -e 
(@@ …)` trick to force the build again. I’ll try again to be sure, but if 
that is the case then this patch can be dropped.

> > 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.

Sorry, I don’t know about that but I can poke around to see if I can find 
something out.

> Are you sure your usage of (assoc-ref %build-inputs "libc") is correct
> here?

I’m not, to be honest. I’m still familiarizing myself with gexps.

> 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?

Are you saying that ‘%build-inputs’ is the union of ‘inputs’  and ‘native-
inputs’? For my own education, do you know where that happens?

The manual and the doc string for ‘build-expression->derivation’ only 
mention that it comes from ‘inputs’. I can send a patch to correct them.

-- 
Thanks,
Thiago

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

[Maxime Devos]

[-- Attachment #1: Type: text/plain, Size: 1744 bytes --]

> [...]
>
> > 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?
> 
> Are you saying that ‘%build-inputs’ is the union of ‘inputs’  and ‘native-
> inputs’? For my own education, do you know where that happens?
> 
> The manual and the doc string for ‘build-expression->derivation’ only 
> mention that it comes from ‘inputs’. I can send a patch to correct them.

I thought "build-expression->derivation" doesn't define %build-inputs
anymore, but apparently it does.  However, note that, on core-updates
at least, gnu-build and gnu-cross-build don't use build-expression->derivation,
instead they use gexp->derivation (see (guix build-system gnu)), and gexp->derivation
doesn't define %build-inputs.

gexp->derivation doesn't define %build-inputs, but gnu-build and gnu-cross-build
do:

        ;; also see with-build-variables
        (define %build-host-inputs
          #+(input-tuples->gexp build-inputs))

        (define %build-target-inputs
          (append #$(input-tuples->gexp host-inputs)
                  #+(input-tuples->gexp target-inputs)))

        (define %build-inputs
          (append %build-host-inputs %build-target-inputs))
        ;; ^ the unio native-inputs, inputs and implicit inputs!

        (define %outputs
          #$(outputs->gexp outputs))

I'm not familiar with 'host-inputs', 'build-inputs' and 'target-inputs'.
They are a ‘bag’ thing, not a ‘package’ thing.  You'll have to look at
'lower' to see how native-inputs and inputs are mapped to host-inputs,
build-inputs and target-inuts.

Greetings,
Maxime.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 260 bytes --]

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

[Thiago Jung Bauermann via Guix-patches via]

Em quinta-feira, 15 de julho de 2021, às 13:00:41 -03, Maxime Devos 
escreveu:
> > [...]
> > 
> > > 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?
> > 
> > Are you saying that ‘%build-inputs’ is the union of ‘inputs’  and
> > ‘native- inputs’? For my own education, do you know where that
> > happens?
> > 
> > The manual and the doc string for ‘build-expression->derivation’ only
> > mention that it comes from ‘inputs’. I can send a patch to correct
> > them.
> 
> I thought "build-expression->derivation" doesn't define %build-inputs
> anymore, but apparently it does.  However, note that, on core-updates
> at least, gnu-build and gnu-cross-build don't use
> build-expression->derivation, instead they use gexp->derivation (see
> (guix build-system gnu)), and gexp->derivation doesn't define
> %build-inputs.
> 
> gexp->derivation doesn't define %build-inputs, but gnu-build and
> gnu-cross-build do:
> 
>         ;; also see with-build-variables
>         (define %build-host-inputs
>           #+(input-tuples->gexp build-inputs))
> 
>         (define %build-target-inputs
>           (append #$(input-tuples->gexp host-inputs)
>                   #+(input-tuples->gexp target-inputs)))
> 
>         (define %build-inputs
>           (append %build-host-inputs %build-target-inputs))
>         ;; ^ the unio native-inputs, inputs and implicit inputs!
> 
>         (define %outputs
>           #$(outputs->gexp outputs))
> 
> I'm not familiar with 'host-inputs', 'build-inputs' and 'target-inputs'.
> They are a ‘bag’ thing, not a ‘package’ thing.  You'll have to look at
> 'lower' to see how native-inputs and inputs are mapped to host-inputs,
> build-inputs and target-inuts.

Ok, I’ll look into that. Thanks for the pointers.

In the meantime, I just confirmed that running this command on core-updates 
does cause glibc-mesboot-2.16 to be built:

--8<---------------cut here---------------start------------->8---
$ ./pre-inst-env guix build \
	--target=powerpc64le-linux-gnu \
	gcc-toolchain@11
substitute: atualizando substitutos de "https://ci.guix.gnu.org"... 100.0%
substitute: atualizando substitutos de "https://bordeaux.guix.gnu.org"... 
100.0%
The following derivations will be built:
   /gnu/store/phgd8m0dqp1gvqys46wy6gdwh1lqsdvm-gcc-toolchain-11.1.0.drv
   /gnu/store/62nvbgjd7vrc09h8r0n05b2bnva69p01-glibc-2.33.drv
   /gnu/store/0qjm3sr7qwv1sc5wfm0n1f6ybk3mvsy5-gawk-boot0-5.1.0.drv
   /gnu/store/2hvdxa6xfsl40h8ih8pvz9r658h80657-patch-mesboot-2.5.9.drv
   /gnu/store/4hs77pg9j543r83mqc2frix6sykj7vzf-make-boot0-4.3.drv
   /gnu/store/4sh57vq45rzkn66k8kii9izdyz738j1n-bzip2-mesboot-1.0.8.drv
   /gnu/store/6a9gx08qwl1rxkxkcmlnn65pszby3ka7-gash-utils-boot-0.1.0.drv
   /gnu/store/kzi9bcm0y4lsnq0wbsxp6ghnif8yh034-gash-boot-0.2.0.drv
   /gnu/store/82b4pi9sh7wgqcpgi6xrpibwc1iqdhji-xz-mesboot-5.0.0.drv
   /gnu/store/ba0vnc5bw91rskk5f3y29fbshysy0776-binutils-mesboot-2.20.1a.drv
   /gnu/store/cjhxxpvbd1ydwzm0663h8l6i40cx81pi-glibc-mesboot-2.16.0.drv
   /gnu/store/d5jx752yqqak9cix1379561p8czhiq93-coreutils-mesboot-8.32.drv
   /gnu/store/hain1fp7kwclrn0mrh9rqidw4vxisz9n-sed-mesboot-4.0.6.drv
   /gnu/store/k12zfxpj6sjjgb30rma0w5fvvmad35hp-gcc-mesboot-4.9.4.drv
   /gnu/store/m7sixkp7k9csfili8q50p8gywpnd05qp-gzip-mesboot-1.2.4.drv
   /gnu/store/nn9yd92g86x4pnm1byjrwhzawrmx4kxg-tar-mesboot-1.22.drv
   /gnu/store/pdjd8jc1sahh2j8yc2bn6z47syzvflrl-gawk-mesboot-3.1.8.drv
   /gnu/store/pivl1bxdv3lgziwkppk5b8qv6hczk8b7-grep-mesboot-2.0.drv
   /gnu/store/ra6hdd7l7dqi8wkm0g4kba2ykd36dbhm-gcc-mesboot-
wrapper-4.9.4.drv
   /gnu/store/vdccj4mvd9626g5hwyljs8i28fx7j6m8-make-mesboot-3.82.drv
   /gnu/store/5q01q11y0p02y9pgqpz9nn6x6zkwriil-diffutils-boot0-3.7.drv
   /gnu/store/bainbjj5p2rcjly5kmx09fr7y2bzrmkc-patch-boot0-2.7.6.drv
   /gnu/store/dd0drjcnd4bsq1qyqx68kykaqrksr1fq-linux-libre-
headers-5.10.35.drv
   /gnu/store/di513kh6hf9r6hl5jnlkzvl014w6db1q-findutils-boot0-4.8.0.drv
   /gnu/store/hvg6ijqsl2s2p0gwnrfzb8aihzann72v-bzip2-boot0-1.0.8.drv
   /gnu/store/j29kp6r510yxlpl47m3havcwd14lmylk-tar-boot0-1.34.drv
   /gnu/store/kzdlk0nrndnzh2ch44ikwm4lmajd0h30-ld-wrapper-boot0-0.drv
   /gnu/store/w9jcb7przdcmh56b197xcm2rx30aw4hz-binutils-cross-
boot0-2.36.1.drv
   /gnu/store/n5l4fnyagzmyrgcndan8dw7531ma4da4-file-boot0-5.39.drv
   /gnu/store/nlrv89bwp4wkj3w36bzmqkijdadbsqny-coreutils-boot0-8.32.drv
   /gnu/store/p5hsziqa8j5adyhmxcc5961kx8aaf1vk-sed-boot0-4.8.drv
   /gnu/store/ncpm5xa6s4a3v1c3sw3478n1d0p99yzr-bash-static-5.1.8.drv
   /gnu/store/mlva2a76j2kgryk9qbfma4f1qbd91gll-glibc-intermediate-2.33.drv
   /gnu/store/r1dwax8yfh1h2g87yij245gfvqq9mg5r-gcc-cross-boot0-10.3.0.drv
   /gnu/store/6xzmm1hbzqbyp0fnp4ay764fl7hlwzqr-libstdc++-boot0-4.9.4.drv
   /gnu/store/lw6xvva92vb6yrg5s73c6m507mmg4wpn-gcc-11.1.0.drv
   /gnu/store/1z1j62pdli02k7x5lqmzm6cv8mi4nmrk-libelf-0.8.13.drv
   /gnu/store/bxaqilawhw2gbrqmcds4dw0xddnmn46x-libstdc++-headers-10.3.0.drv
   /gnu/store/v8g8wjzq6fvl32965xdz2z4w6zk1w91w-binutils-2.36.1.drv
   /gnu/store/62nvbgjd7vrc09h8r0n05b2bnva69p01-glibc-2.33.drv
   /gnu/store/v8i4vbz1s3idiqyi7cvwplblaxlyrap6-ld-wrapper-0.drv
   /gnu/store/2lx0j1j5qn3g77kmhy6kzxkbqgmajz3x-libatomic-ops-7.6.10.drv
   /gnu/store/09falwp7jqb9kz4qrqassbs37cmgxrrk-gcc-10.3.0.drv
   /gnu/store/bfbaw9js573ig21a6k2cg4bv7j7q1s5v-libstdc++-10.3.0.drv
--8<---------------cut here---------------end--------------->8---

So either something like this patch is needed, or some other change to 
avoid building glibc-mesboot-2.16 for powerpc64le-linux-gnu.

-- 
Thanks,
Thiago

[bug#49565] [PATCH core-updates] gnu: bootstrap: Use %current-target-system to decide bootstrap path

[Thiago Jung Bauermann via Guix-patches via]

When cross-building a non-x86 gcc-toolchain on an x86 machine,
‘%current-target’ has the x86 system value and Guix tries to use the
mesboot packages for the bootstrap – which don't work because they’re
currently x86-only.

Therefore look at ‘%current-target-system’ first, which has the non-x86
system value.

* gnu/packages/bootstrap.scm (%bootstrap-inputs): Check
‘%current-target-system’ before ‘%current-system’ to decide whether to use
the mesboot path.
* gnu/packages/commencement.scm (%bootstrap-inputs+toolchain): Ditto.
---
 gnu/packages/bootstrap.scm    | 2 +-
 gnu/packages/commencement.scm | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

Hi,

As Maxime Devos mentined previously, glibc-mesboot is only supported on
i686-linux and x86_64-linux and not powerpc64le-linux so it’s strange that
it’s being built on my system. Investigating further, I believe the the
problem is the one described on the commit message above.

With the patch applied on core-updates, I can now get the same error that
the CI is getting when trying to cross-compile a gcc-toolchain package, as
seen here:

https://ci.guix.gnu.org/build/667452/details

But I can’t explain why I see this problem on my machine while it doesn’t
happen on the CI one. Perhaps because I’m running Guix on a foreign distro
(Ubuntu), while the CI presumably uses Guix System?

Here are the derivations that are built now:

--8<---------------cut here---------------start------------->8---
$ ./pre-inst-env guix build \
	--target=powerpc64le-linux-gnu \
	gcc-toolchain@11
substitute: atualizando substitutos de "https://ci.guix.gnu.org"...  100.0%
substitute: atualizando substitutos de "https://bordeaux.guix.gnu.org"... 100.0%
The following derivations will be built:
   /gnu/store/3smglg4didq9bizfa6mpgr3mwyl025bg-gcc-toolchain-11.1.0.drv
   /gnu/store/bqs0df2b3zalz3f6cs3blx3r13f8agwx-linux-libre-headers-5.10.35.drv
   /gnu/store/adi4bagfjzja2cy0xd4zsjrhrx4l8zzh-gcc-bootstrap-0.drv
   /gnu/store/lw6xvva92vb6yrg5s73c6m507mmg4wpn-gcc-11.1.0.drv
   /gnu/store/qm1lgdvlc6wkch2z6qiglqgfjrc9dl52-binutils-2.36.1.drv
   /gnu/store/23fsjsynp3ryb6npgiipx327ag7dd394-file-boot0-5.39.drv
   /gnu/store/m69xqa8k199gnphplml2pc4qbl0w07pj-make-boot0-4.3.drv
   /gnu/store/35v7glpl1p0sbkmyyls4nlcvfdq80bp4-findutils-boot0-4.8.0.drv
   /gnu/store/3lsjr0fpxx07h7kz42sqqkgqi76wr92w-diffutils-boot0-3.7.drv
   /gnu/store/8v38wv9nd9wa1v0xmb38la68pck43xsr-sed-boot0-4.8.drv
   /gnu/store/dxkjjafij00vda2a515clxq2s75l0pxy-patch-boot0-2.7.6.drv
   /gnu/store/g7zi4asrxwqjy2zskgisw098vs49smhn-tar-boot0-1.34.drv
   /gnu/store/k4p3hhphaw59afaxrhyzc58041736qp9-gawk-boot0-5.1.0.drv
   /gnu/store/qr4hzgwji76cr18c2b4ii10wciyplis3-coreutils-boot0-8.32.drv
   /gnu/store/r16wrs5pfad62pp104m58d6z3r010mq6-glibc-2.33.drv
   /gnu/store/crdznbwd3dq9xrmrxzjk1jl80fb2d1ws-gcc-cross-boot0-10.3.0.drv
   /gnu/store/i337vhnb6gh510s0cprbww1l3qila759-libstdc++-boot0-4.9.4.drv
   /gnu/store/vvkqxj9c4710jajddrqd7qbq1vhy1b2q-bzip2-boot0-1.0.8.drv
   /gnu/store/wry17xmsdh3dg33f4397a609kix5492q-binutils-cross-boot0-2.36.1.drv
   /gnu/store/f2yibv3n2ya2s2hcv2n103bmfb39q0q1-bash-static-5.1.8.drv
   /gnu/store/rn9xwjxjxdr6chwr5bdm0law300120yj-ld-wrapper-boot0-0.drv
   /gnu/store/vnaw38hssdshzsy17vmmy7x7zh3ni7zi-glibc-intermediate-2.33.drv
   /gnu/store/qzhgyd8qnwhy46ajsr1156zap6sryxvf-ld-wrapper-0.drv
   /gnu/store/5g8dn0w3k3m2famxndzxywxl6v3r79cm-libunistring-0.9.10.drv
   /gnu/store/0ycvzp0zmlqac5k3b32a7kb9y5z8sz09-gcc-10.3.0.drv
   /gnu/store/dh10c2zsxyv0i3j43q81xfmkhsnh03sh-libstdc++-10.3.0.drv
   /gnu/store/xwifg8mb9zh0azyxccls9q6gcb56p14h-ld-wrapper-boot3-0.drv
   /gnu/store/yljl3dspmzk6256sdl56swsq2r694nsi-zlib-1.2.11.drv
   /gnu/store/w87mmrp0c5irjmqhjj76m27i39zgj3xf-bash-minimal-5.1.8.drv
   /gnu/store/aag6c2sy2w3xyzs4nm0nfwsqw9c1xkvi-libgc-8.0.4.drv
   /gnu/store/vvljjz5dj38yqfd813z6z6xmwsk32jbg-libatomic-ops-7.6.10.drv
   /gnu/store/k4rzmyxidag567qvf7rkpwl0h041vczm-guile-3.0.7.drv
   /gnu/store/d608rkzh04rlaivcm9y0hsj4icanhdyp-libffi-3.3.drv
   /gnu/store/r16wrs5pfad62pp104m58d6z3r010mq6-glibc-2.33.drv
--8<---------------cut here---------------end--------------->8---


diff --git a/gnu/packages/bootstrap.scm b/gnu/packages/bootstrap.scm
index 5a8028a4652c..b14dc63062e8 100644
--- a/gnu/packages/bootstrap.scm
+++ b/gnu/packages/bootstrap.scm
@@ -927,7 +927,7 @@ exec ~a/bin/.gcc-wrapped -B~a/lib \
 (define (%bootstrap-inputs)
   ;; The initial, pre-built inputs.  From now on, we can start building our
   ;; own packages.
-  (match (%current-system)
+  (match (or (%current-target-system) (%current-system))
     ((or "i686-linux" "x86_64-linux")
      `(("linux-libre-headers" ,%bootstrap-linux-libre-headers)
        ("bootstrap-mescc-tools" ,%bootstrap-mescc-tools)
diff --git a/gnu/packages/commencement.scm b/gnu/packages/commencement.scm
index fb028390a260..2af3dead3c73 100644
--- a/gnu/packages/commencement.scm
+++ b/gnu/packages/commencement.scm
@@ -2396,7 +2396,7 @@ exec " gcc "/bin/" program
 (define (%bootstrap-inputs+toolchain)
   ;; The traditional bootstrap-inputs.  For the i686-linux, x86_64-linux
   ;; Scheme-only bootstrap the actual reduced set with bootstrapped toolchain.
-  (match (%current-system)
+  (match (or (%current-target-system) (%current-system))
     ((or "i686-linux" "x86_64-linux")
      (%boot-mesboot6-inputs))
     (_

[bug#49565] [PATCH core-updates] gnu: bootstrap: Use %current-target-system to decide bootstrap path

[Maxime Devos]

[-- Attachment #1: Type: text/plain, Size: 1171 bytes --]

Hi,


> diff --git a/gnu/packages/bootstrap.scm b/gnu/packages/bootstrap.scm
> index 5a8028a4652c..b14dc63062e8 100644
> --- a/gnu/packages/bootstrap.scm
> +++ b/gnu/packages/bootstrap.scm
> @@ -927,7 +927,7 @@ exec ~a/bin/.gcc-wrapped -B~a/lib \
>  (define (%bootstrap-inputs)
>    ;; The initial, pre-built inputs.  From now on, we can start building our
>    ;; own packages.
> -  (match (%current-system)
> +  (match (or (%current-target-system) (%current-system))
>      ((or "i686-linux" "x86_64-linux")
>       `(("linux-libre-headers" ,%bootstrap-linux-libre-headers)
>         ("bootstrap-mescc-tools" ,%bootstrap-mescc-tools)

This makes sense to me.
However, you may need to modify 'package-from-tarball' as well,
replacing
("tarball" ,(bootstrap-origin (source (%current-system))))))
with
("tarball" ,(bootstrap-origin (source (or (%current-target-system) (%current-system)))))))

Could you verify the architecture of the binaries in the output
of "./pre-inst-env guix build gcc-toolchain@11 --target=powerpc64le-linux-gnu",
and its references (you can use "guix gc --references /gnu/store/..." and objdump)?

Greetings,
Maxime.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 260 bytes --]

[bug#49565] [PATCH core-updates] gnu: bootstrap: Use %current-target-system to decide bootstrap path

[Thiago Jung Bauermann via Guix-patches via]

Hello,

Em sexta-feira, 16 de julho de 2021, às 05:20:20 -03, Maxime Devos
escreveu:
> Hi,
> 
> > diff --git a/gnu/packages/bootstrap.scm b/gnu/packages/bootstrap.scm
> > index 5a8028a4652c..b14dc63062e8 100644
> > --- a/gnu/packages/bootstrap.scm
> > +++ b/gnu/packages/bootstrap.scm
> > @@ -927,7 +927,7 @@ exec ~a/bin/.gcc-wrapped -B~a/lib \
> > 
> >  (define (%bootstrap-inputs)
> >  
> >    ;; The initial, pre-built inputs.  From now on, we can start
> >    building our ;; own packages.
> > 
> > -  (match (%current-system)
> > +  (match (or (%current-target-system) (%current-system))
> > 
> >      ((or "i686-linux" "x86_64-linux")
> >      
> >       `(("linux-libre-headers" ,%bootstrap-linux-libre-headers)
> >       
> >         ("bootstrap-mescc-tools" ,%bootstrap-mescc-tools)
> 
> This makes sense to me.
> However, you may need to modify 'package-from-tarball' as well,
> replacing
> ("tarball" ,(bootstrap-origin (source (%current-system))))))
> with
> ("tarball" ,(bootstrap-origin (source (or (%current-target-system)
> (%current-system)))))))

Thanks! I did that but it doesn’t work in this case because the ‘source’
functions expect a Nix system string and ‘%current-target-system’ is a
GNU triplet string. After I defined a function which calls
‘gnu-triplet->nix-system’ on it, then it worked.

This made me realize that all places which do
`(or (%current-target-system) (%current-system))` have this inconsistency.
I’m currently preparing a couple of patches to clean them up.

> Could you verify the architecture of the binaries in the output
> of "./pre-inst-env guix build gcc-toolchain@11
> --target=powerpc64le-linux-gnu", and its references (you can use "guix
> gc --references /gnu/store/..." and objdump)?

I can’t do that on the output because the GCC build fails – which is what
I originally set out to investigate when I stumbled on this problem. :-)

I did a `guix build -K …` and this is the result on the build directory:

--8<---------------cut here---------------start------------->8---
$ ./pre-inst-env guix build \
	-K \
	--target=powerpc64le-linux-gnu \
	gcc-toolchain@11
    ⋮
<snip lots of output>
    ⋮
make[1]: *** [Makefile:11850: all-target-libstdc++-v3] Error 2
make[1]: Leaving directory '/tmp/guix-build-gcc-11.1.0.drv-0/build'
make: *** [Makefile:962: all] Error 2
error: in phase 'build': uncaught exception:
%exception #<&invoke-error program: "make" arguments: ("-j" "8" "CFLAGS=-g0 -O2") exit-status: 2 term-signal: #f stop-signal: #f>
phase `build' failed after 810.7 seconds
command "make" "-j" "8" "CFLAGS=-g0 -O2" failed with status 2
note: keeping build directory `/tmp/guix-build-gcc-11.1.0.drv-0'
builder for `/gnu/store/lw6xvva92vb6yrg5s73c6m507mmg4wpn-gcc-11.1.0.drv' failed with exit code 1
build of /gnu/store/lw6xvva92vb6yrg5s73c6m507mmg4wpn-gcc-11.1.0.drv failed
View build log at '/var/log/guix/drvs/lw/6xvva92vb6yrg5s73c6m507mmg4wpn-gcc-11.1.0.drv.bz2'.
cannot build derivation `/gnu/store/gnsdxz7r9l6d9wafwcms2dgz6hhi6gvn-gcc-toolchain-11.1.0.drv': 1 dependencies couldn't be built
guix build: error: build of `/gnu/store/gnsdxz7r9l6d9wafwcms2dgz6hhi6gvn-gcc-toolchain-11.1.0.drv' failed
$ find /tmp/guix-build-gcc-11.1.0.drv-0 -name '*.o' -exec file '{}' ';' | cut -d: -f2 | sort | uniq -c
      3  ELF 64-bit LSB relocatable, 64-bit PowerPC or cisco 7500, version 1 (GNU/Linux), with debug_info, not stripped
    235  ELF 64-bit LSB relocatable, 64-bit PowerPC or cisco 7500, version 1 (SYSV), not stripped
   1496  ELF 64-bit LSB relocatable, 64-bit PowerPC or cisco 7500, version 1 (SYSV), with debug_info, not stripped
    118  ELF 64-bit LSB relocatable, x86-64, version 1 (SYSV), not stripped
     14  ELF 64-bit LSB relocatable, x86-64, version 1 (SYSV), with debug_info, not stripped
--8<---------------cut here---------------end--------------->8---

The vast majority of the files are ppc64le. Of the x86-64 ones, 87 are in
/tmp/guix-build-gcc-11.1.0.drv-0/build/build-x86_64-unknown-linux-gnu/ and
45 are in /tmp/guix-build-gcc-11.1.0.drv-0/build/gcc/build/.

I’m not very familiar with GCC’s build system, so I can’t say whether it’s
expected to have it create these x86-64 objects, but I wouldn’t be surprised
if it needed to build some native auxiliaryprograms for the build process.

Because there’s no finished output, I wasn’t able to check for references.

I can make a more conclusive test when this GCC cross build problem is fixed.

-- 
Thanks,
Thiago

[bug#49565] [PATCH core-updates] gnu: bootstrap: Use %current-target-system to decide bootstrap path

[Maxime Devos]

[-- Attachment #1: Type: text/plain, Size: 1730 bytes --]

Thiago Jung Bauermann schreef op vr 16-07-2021 om 17:01 [-0300]:
> Thanks! I did that but it doesn’t work in this case because the ‘source’
> functions expect a Nix system string and ‘%current-target-system’ is a
> GNU triplet string. After I defined a function which calls
> ‘gnu-triplet->nix-system’ on it, then it worked.
> 
> This made me realize that all places which do
> `(or (%current-target-system) (%current-system))` have this inconsistency.
> I’m currently preparing a couple of patches to clean them up.

There are some places where it doesn't matter if it's the GNU triplet
or Nix system string (e.g. libflame, tlsdate) and there are some places
where the difference does matter (e.g. the definition of libpasastro
seems buggy o me).

> The vast majority of the files are ppc64le. Of the x86-64 ones, 87 are in
> /tmp/guix-build-gcc-11.1.0.drv-0/build/build-x86_64-unknown-linux-gnu/ and
> 45 are in /tmp/guix-build-gcc-11.1.0.drv-0/build/gcc/build/.
> 
> I’m not very familiar with GCC’s build system, so I can’t say whether it’s
> expected to have it create these x86-64 objects, but I wouldn’t be surprised
> if it needed to build some native auxiliaryprograms for the build process.

When compiling GCC (version M) with GCC (version N), first version M is compiled
using version N, then the resulting gcc is used to compile GCC (version M) again.
As I understand it, the idea is to let the end result be independent from the
compiler one started out with.

> Because there’s no finished output, I wasn’t able to check for references.
> 
> I can make a more conclusive test when this GCC cross build problem is fixed.

Ok.

Greetings,
Maxime.



[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 260 bytes --]

[bug#49565] [PATCH core-updates] gnu: bootstrap: Use %current-target-system to decide bootstrap path

[Thiago Jung Bauermann via Guix-patches via]

Em domingo, 18 de julho de 2021, às 13:10:40 -03, Maxime Devos escreveu:
> Thiago Jung Bauermann schreef op vr 16-07-2021 om 17:01 [-0300]:
> > Thanks! I did that but it doesn’t work in this case because the
> > ‘source’
> > functions expect a Nix system string and ‘%current-target-system’ is a
> > GNU triplet string. After I defined a function which calls
> > ‘gnu-triplet->nix-system’ on it, then it worked.
> > 
> > This made me realize that all places which do
> > `(or (%current-target-system) (%current-system))` have this
> > inconsistency. I’m currently preparing a couple of patches to clean
> > them up.
> 
> There are some places where it doesn't matter if it's the GNU triplet
> or Nix system string (e.g. libflame, tlsdate) and there are some places
> where the difference does matter (e.g. the definition of libpasastro
> seems buggy o me).

True. I’m going through the places using ‘%current-target-system’ and 
fixing the ones that seem buggy to me. I changed libpasastro here. I should 
have something to send in the next few days.

> > The vast majority of the files are ppc64le. Of the x86-64 ones, 87 are
> > in
> > /tmp/guix-build-gcc-11.1.0.drv-0/build/build-x86_64-unknown-linux-gnu/
> > and 45 are in /tmp/guix-build-gcc-11.1.0.drv-0/build/gcc/build/.
> > 
> > I’m not very familiar with GCC’s build system, so I can’t say whether
> > it’s expected to have it create these x86-64 objects, but I wouldn’t
> > be surprised if it needed to build some native auxiliaryprograms for
> > the build process.
> When compiling GCC (version M) with GCC (version N), first version M is
> compiled using version N, then the resulting gcc is used to compile GCC
> (version M) again. As I understand it, the idea is to let the end result
> be independent from the compiler one started out with.

Makes sense. Thanks for clarifying!

-- 
Thanks,
Thiago

[bug#49565] [PATCH core-updates v2] gnu: bootstrap: Use %current-target-system to decide bootstrap path

[Thiago Jung Bauermann via Guix-patches via]

When cross-building a non-x86 gcc-toolchain on an x86 machine,
‘%current-target’ has the x86 system value and Guix tries to use the
mesboot packages for the bootstrap – which don’t work because they’re
currently x86-only.

So introduce the ‘current-target-nix-system’ procedure which looks at
‘%current-target-system’ first (converting it to a Nix system string) and
use it to decide the bootstrap path. The procedure is factored out from
‘glibc-dynamic-linker’.

Also use it in ‘package-from-tarball’, which needs to take the target
system into account as well – thanks to Maxime Devos for pointing it out.

* gnu/packages/bootstrap.scm (package-from-tarball): Pass result of
‘current-target-nix-system’ to ‘source’ procedure.
(glibc-dynamic-linker): Use result of ‘current-target-nix-system’ as
default value for ‘system’ argument.
(%bootstrap-inputs): Use ‘current-target-nix-system’ to decide whether to
use the mesboot path.
* gnu/packages/commencement.scm (%bootstrap-inputs+toolchain): Likewise.
* guix/utils.scm (current-target-nix-system): Define.
---
 gnu/packages/bootstrap.scm    | 8 +++-----
 gnu/packages/commencement.scm | 2 +-
 guix/utils.scm                | 7 +++++++
 3 files changed, 11 insertions(+), 6 deletions(-)

Hi,

This is the new version of this patch. Thank you Maxime Devos for reviewing the
previous version and pointing out the change needed in ‘package-from-tarball’.

This version makes that change, and also defines a helper function in
`(guix utils)` which returns the Nix system identifier for the current target
– regardless of whether we are cross-building or not.

Before the patch, these are the derivations that Guix tries to build when
cross-compiling gcc-toolchain@11. Note the ‘mesboot’ packages:

--8<---------------cut here---------------start------------->8---
$ ./pre-inst-env guix build --target=powerpc64le-linux-gnu gcc-toolchain@11
substitute: atualizando substitutos de "https://ci.guix.gnu.org"... 100.0%
substitute: atualizando substitutos de "https://bordeaux.guix.gnu.org"... 100.0%
The following derivations will be built:
   /gnu/store/3hrzq7fxj0cxgxkjybki2yi7dj70sgg8-gcc-toolchain-11.1.0.drv
   /gnu/store/2xpiffvzzizrjx48ghqac3rgh1cnljv7-linux-libre-headers-5.10.35.drv
   /gnu/store/4xlm78m6wl56gn4gpifvy8721amhi81j-binutils-2.36.1.drv
   /gnu/store/05lnycy4lmn0768r41sgikg795zk9mqg-binutils-cross-boot0-2.36.1.drv
   /gnu/store/1q62fcaj2gc9mnwvv6cicch6gc7qrnp0-binutils-mesboot-2.20.1a.drv
   /gnu/store/1yjrfb846y1mnc7mgab38jbv7pv0hgbh-tar-boot0-1.34.drv
   /gnu/store/9c7a2p899ivz16636prf44q0q61i4376-patch-mesboot-2.5.9.drv
   /gnu/store/9rmnv55i966wfkx0di4h6p8197hy2836-grep-mesboot-2.0.drv
   /gnu/store/advn8cgpcf9fi6424l8bs16r5mvfqs04-gcc-mesboot-wrapper-4.9.4.drv
   /gnu/store/bpghw1m585q2wjc0z4in9w0hcpxgiidw-gzip-mesboot-1.2.4.drv
   /gnu/store/bx9lr1bg5491dc9i5p2b6zgsq0ahajxb-gcc-mesboot-4.9.4.drv
   /gnu/store/dfijxa9mnlymzmsl571qlxx0qc65kxzi-tar-mesboot-1.22.drv
   /gnu/store/hp2f5sw9d189p7z930b63wr8k3j9k6j0-coreutils-mesboot-8.32.drv
   /gnu/store/i584nxkb39n67vzq5r3yh6spqppzrj43-bzip2-mesboot-1.0.8.drv
   /gnu/store/j1accym68y6l8pxz8095jpkwgp3ciphi-gawk-mesboot-3.1.8.drv
   /gnu/store/jlwyxh3k6hvpmy60g0ygwnncq66kn590-gash-utils-boot-0.1.0.drv
   /gnu/store/9mxvccmf0b8fwq0k7lw0ndsdsbz9y8vn-gash-boot-0.2.0.drv
   /gnu/store/p43yklj8d615y68jhcvycg9i3k3bqj2g-xz-mesboot-5.0.0.drv
   /gnu/store/rxn5c166a6p0p3y2hlyk67f91a504kfa-make-mesboot-3.82.drv
   /gnu/store/sgwdni3iwwrb4ahsnwm43528fzr5csiv-sed-mesboot-4.0.6.drv
   /gnu/store/xxaccspqlg90v3cxrbvslva6s8gwxzi9-make-boot0-4.3.drv
   /gnu/store/zghmr1xyw5ip3wpi1qw2ysc7p6i75d54-glibc-mesboot-2.16.0.drv
   /gnu/store/64cway6pvw5fk7csym2k9i77rhp1pl46-coreutils-boot0-8.32.drv
   /gnu/store/7hvyky0i1hf3xbd698rr305br881pwz6-diffutils-boot0-3.7.drv
   /gnu/store/hq1lijdac3vqx811jzsg0wizsbgwgpaa-gawk-boot0-5.1.0.drv
   /gnu/store/i173n23qpssi7idck4jn7399bfkldlfs-sed-boot0-4.8.drv
   /gnu/store/l8kbhm6m9rbwkxn7zv1d06wbl2gi88wp-findutils-boot0-4.8.0.drv
   /gnu/store/pfq7g9jx16jlk3829312h88n0k1jnfns-patch-boot0-2.7.6.drv
   /gnu/store/qp3yg441ybh6bv44lrcxyp6rzyf0djii-file-boot0-5.39.drv
   /gnu/store/x4m7lff1ps5mas719815d54x6x1zwcv3-bzip2-boot0-1.0.8.drv
   /gnu/store/h5hwcnr7z57hb9b8bhhx7s22kfawqr0d-ld-wrapper-boot0-0.drv
   /gnu/store/v9p5fm974mj4d99vdpp9dhrvpwd4kfgs-glibc-2.33.drv
   /gnu/store/0kjyjcxzk5mv6zm86x8f18sbsb9m48k8-bash-static-5.1.8.drv
   /gnu/store/6h220skb9ak8ppv5417i8cbry1byv73a-glibc-intermediate-2.33.drv
   /gnu/store/rwczga96661d70jcqds8w8pr5s084mh4-gcc-cross-boot0-10.3.0.drv
   /gnu/store/cglgsds6hxy9swdyymgam9l3rfwizyfr-libstdc++-boot0-4.9.4.drv
   /gnu/store/c63lqgh0x2rx1az0ds4b2ma9vgiry31j-gcc-11.1.0.drv
   /gnu/store/f4fwnxsha5h2pk750r2p09cnhbhc3nm3-ld-wrapper-0.drv
   /gnu/store/605p0jq8wv879n3y6fbqxvaiww1kjaql-libunistring-0.9.10.drv
   /gnu/store/5irbp0c5zzvs50wlznpfxcxr8mfndwy9-gcc-10.3.0.drv
   /gnu/store/byfbnlkwj9pjwnkx69fi2ycnqdvz2znv-ld-wrapper-boot3-0.drv
   /gnu/store/fbm3gv13nggw2qcvxmlccqgi0izzgdwn-libstdc++-10.3.0.drv
   /gnu/store/vhwmw9p8l3sysqlm8bh14xkfw1afqqcj-zlib-1.2.11.drv
   /gnu/store/60jiv5k1lg2krj3b0f9x7f26ywrda0mw-bash-minimal-5.1.8.drv
   /gnu/store/i0lk6zd2vwqqlhn8kkf0529x896lnzr1-guile-3.0.7.drv
   /gnu/store/r25wjwjbb13yk8yc4bm77dxxcq9qvx9y-libatomic-ops-7.6.10.drv
   /gnu/store/ry3zxxjsnhpdphvnnr991x9yk7gljxy9-libffi-3.3.drv
   /gnu/store/y26kx37mkidni8jj4sjn0ryy1wq1pqvs-libgc-8.0.4.drv
   /gnu/store/v9p5fm974mj4d99vdpp9dhrvpwd4kfgs-glibc-2.33.drv
--8<---------------cut here---------------end--------------->8---

These are the derivations built after the patch is applied. Note that there
is no ‘mesboot’ package:

--8<---------------cut here---------------start------------->8---
$ ./pre-inst-env guix build --target=powerpc64le-linux-gnu gcc-toolchain@11
substitute: atualizando substitutos de "https://ci.guix.gnu.org"... 100.0%
substitute: atualizando substitutos de "https://bordeaux.guix.gnu.org"... 100.0%
The following derivations will be built:
   /gnu/store/wnllxi9hz868ymmhl9y1izry825azal7-gcc-toolchain-11.1.0.drv
   /gnu/store/3mzbrsijxql7np8zzgs5z6svl4iw3si8-ld-wrapper-0.drv
   /gnu/store/2qbrgj46x4ywkl5icxl13iqalzy1y464-libgc-8.0.4.drv
   /gnu/store/0d3sx0dvn32afifnhsz28yvf9p8shh49-findutils-boot0-4.8.0.drv
   /gnu/store/c497lf15zqz2xx75idh091sp4i3il5zh-make-boot0-4.3.drv
   /gnu/store/dnycxgnzfpj1vc8aaxgnb4gj1m8cv2fa-diffutils-boot0-3.7.drv
   /gnu/store/11z204mvwgimbwifvwd7di76k49kwh1n-tar-boot0-1.34.drv
   /gnu/store/2ykvg2wms8f5bqgqn0fw28grssmkx43f-libatomic-ops-7.6.10.drv
   /gnu/store/3lyp33ib5v3zmykgk53m3plmm7n122j0-file-boot0-5.39.drv
   /gnu/store/4942syn0qn16cg97x27l26rddv5pf297-gawk-boot0-5.1.0.drv
   /gnu/store/5jzrc7l0yjd3wagbfkgdb29jb7cxl97i-bash-minimal-5.1.8.drv
   /gnu/store/7ivfiaav5af41jcpij0lg8ig2vhl46cz-patch-boot0-2.7.6.drv
   /gnu/store/975bjay86c67q0agahxjbalbphd6i2dn-ld-wrapper-boot0-0.drv
   /gnu/store/gbzc67364szqynv0k8ncgvb4r9v0s8gl-binutils-cross-boot0-2.36.1.drv
   /gnu/store/aa1pb63rgm7mgmljq4nqxw5dxlgf1x0k-coreutils-boot0-8.32.drv
   /gnu/store/i33n2m4883668c26kfbcn4r6k5mb6i3q-bzip2-boot0-1.0.8.drv
   /gnu/store/rdigl19v5302arib6i0ic2nhdl8588yv-sed-boot0-4.8.drv
   /gnu/store/d407z0m02m85hbrgf6c0bbvbc72v9wp8-gcc-10.3.0.drv
   /gnu/store/6qy66x2s6izvkiggild5bwi7b1p3i14c-zlib-1.2.11.drv
   /gnu/store/rfji2zr6yicw3vjcksjzk7zc7hxmh0pa-glibc-2.33.drv
   /gnu/store/1knbpbymgj1rggdlkdpz2k9i2sh1hjwk-bash-static-5.1.8.drv
   /gnu/store/05667q3f8yl7fbny1sxkli66rcl8gyrf-glibc-intermediate-2.33.drv
   /gnu/store/5lmmwvhf8gjzw31a0fv7gkl9zcaj76r6-gcc-cross-boot0-10.3.0.drv
   /gnu/store/wkmp9i5il6afhrn6d3lkzf7wminx6rax-libstdc++-boot0-4.9.4.drv
   /gnu/store/b2bjf70ks7f55z1ady9ng34m7iyk8w5a-binutils-2.36.1.drv
   /gnu/store/dqgshra3sbikll475m95slnyqzkmagsn-libstdc++-10.3.0.drv
   /gnu/store/fr2q75l4rdymmcy6wdmjc560vn4l7lxi-ld-wrapper-boot3-0.drv
   /gnu/store/c7i6v0w124ckyvb6pizbg4fqhgwf6gi5-guile-3.0.7.drv
   /gnu/store/ar81shvadvhzkyq4ygln66gpy7xrvjy4-libffi-3.3.drv
   /gnu/store/w8p9y4llj6a91blrf574yjns09vbnkbl-libunistring-0.9.10.drv
   /gnu/store/c63lqgh0x2rx1az0ds4b2ma9vgiry31j-gcc-11.1.0.drv
   /gnu/store/rfji2zr6yicw3vjcksjzk7zc7hxmh0pa-glibc-2.33.drv
--8<---------------cut here---------------end--------------->8---

This is all on today's core-updates branch, at commit:

db5962c68099 gnu: ghostscript: Improve reproducibility of PDF document generation

diff --git a/gnu/packages/bootstrap.scm b/gnu/packages/bootstrap.scm
index 5a8028a4652c..d1493e4c7ec7 100644
--- a/gnu/packages/bootstrap.scm
+++ b/gnu/packages/bootstrap.scm
@@ -266,7 +266,7 @@ or false to signal an error."
     (inputs
      `(("tar" ,(bootstrap-executable "tar" (%current-system)))
        ("xz"  ,(bootstrap-executable "xz" (%current-system)))
-       ("tarball" ,(bootstrap-origin (source (%current-system))))))
+       ("tarball" ,(bootstrap-origin (source (current-target-nix-system))))))
     (source #f)
     (synopsis description)
     (description description)
@@ -299,9 +299,7 @@ or false to signal an error."
                                  package-with-bootstrap-guile)))))
 
 (define* (glibc-dynamic-linker
-          #:optional (system (or (and=> (%current-target-system)
-                                        gnu-triplet->nix-system)
-                                 (%current-system))))
+          #:optional (system (current-target-nix-system)))
   "Return the name of Glibc's dynamic linker for SYSTEM."
   ;; See the 'SYSDEP_KNOWN_INTERPRETER_NAMES' cpp macro in libc.
   (cond ((string=? system "x86_64-linux") "/lib/ld-linux-x86-64.so.2")
@@ -927,7 +925,7 @@ exec ~a/bin/.gcc-wrapped -B~a/lib \
 (define (%bootstrap-inputs)
   ;; The initial, pre-built inputs.  From now on, we can start building our
   ;; own packages.
-  (match (%current-system)
+  (match (current-target-nix-system)
     ((or "i686-linux" "x86_64-linux")
      `(("linux-libre-headers" ,%bootstrap-linux-libre-headers)
        ("bootstrap-mescc-tools" ,%bootstrap-mescc-tools)
diff --git a/gnu/packages/commencement.scm b/gnu/packages/commencement.scm
index a04bb83c3d2d..030dfad970a7 100644
--- a/gnu/packages/commencement.scm
+++ b/gnu/packages/commencement.scm
@@ -2396,7 +2396,7 @@ exec " gcc "/bin/" program
 (define (%bootstrap-inputs+toolchain)
   ;; The traditional bootstrap-inputs.  For the i686-linux, x86_64-linux
   ;; Scheme-only bootstrap the actual reduced set with bootstrapped toolchain.
-  (match (%current-system)
+  (match (current-target-nix-system)
     ((or "i686-linux" "x86_64-linux")
      (%boot-mesboot6-inputs))
     (_
diff --git a/guix/utils.scm b/guix/utils.scm
index c5a3a52f9dbc..0d438a00ce00 100644
--- a/guix/utils.scm
+++ b/guix/utils.scm
@@ -85,6 +85,7 @@
             gnu-triplet->nix-system
             %current-system
             %current-target-system
+            current-target-nix-system
             package-name->name+version
             target-linux?
             target-hurd?
@@ -630,6 +631,12 @@ returned by `config.guess'."
   ;; cross-building to.
   (make-parameter #f))
 
+(define (current-target-nix-system)
+  "Return the Nix system identifier for the current target, whether we are
+cross-building or not."
+  (or (and=> (%current-target-system) gnu-triplet->nix-system)
+      (%current-system)))
+
 (define* (package-name->name+version spec
                                      #:optional (delimiter #\@))
   "Given SPEC, a package name like \"foo@0.9.1b\", return two values: \"foo\"

[bug#49565] [PATCH core-updates v2] gnu: bootstrap: Use %current-target-system to decide bootstrap path

[Thiago Jung Bauermann via Guix-patches via]

Hello,

Em segunda-feira, 19 de julho de 2021, às 21:01:33 -03,
Thiago Jung Bauermann escreveu:
> Before the patch, these are the derivations that Guix tries to build when
> cross-compiling gcc-toolchain@11. Note the ‘mesboot’ packages:

One thing I forgot to mention, and which significance only dawned on me
later: there was a change in Guix behavior between versions of core-updates
since I posted v1 of this patch.

Before, I was getting a Guix exception during the build of glibc-mesboot,
as detailed in the first message in this issue. Now, the mesboot packages
build fine and the command below goes all the way to the gcc-11 package
just like when this patch is applied.

> --8<---------------cut here---------------start------------->8---
> $ ./pre-inst-env guix build --target=powerpc64le-linux-gnu gcc-toolchain@11
> substitute: atualizando substitutos de "https://ci.guix.gnu.org"... 100.0% 
> substitute: atualizando substitutos de "https://bordeaux.guix.gnu.org"... 100.0%
> The following derivations will be built:
> /gnu/store/3hrzq7fxj0cxgxkjybki2yi7dj70sgg8-gcc-toolchain-11.1.0.drv
> /gnu/store/2xpiffvzzizrjx48ghqac3rgh1cnljv7-linux-libre-headers-5.10.35.drv
> /gnu/store/4xlm78m6wl56gn4gpifvy8721amhi81j-binutils-2.36.1.drv
> /gnu/store/05lnycy4lmn0768r41sgikg795zk9mqg-binutils-cross-boot0-2.36.1.drv
> /gnu/store/1q62fcaj2gc9mnwvv6cicch6gc7qrnp0-binutils-mesboot-2.20.1a.drv
> /gnu/store/1yjrfb846y1mnc7mgab38jbv7pv0hgbh-tar-boot0-1.34.drv
> /gnu/store/9c7a2p899ivz16636prf44q0q61i4376-patch-mesboot-2.5.9.drv
> /gnu/store/9rmnv55i966wfkx0di4h6p8197hy2836-grep-mesboot-2.0.drv
> /gnu/store/advn8cgpcf9fi6424l8bs16r5mvfqs04-gcc-mesboot-wrapper-4.9.4.drv
> /gnu/store/bpghw1m585q2wjc0z4in9w0hcpxgiidw-gzip-mesboot-1.2.4.drv
> /gnu/store/bx9lr1bg5491dc9i5p2b6zgsq0ahajxb-gcc-mesboot-4.9.4.drv
> /gnu/store/dfijxa9mnlymzmsl571qlxx0qc65kxzi-tar-mesboot-1.22.drv
> /gnu/store/hp2f5sw9d189p7z930b63wr8k3j9k6j0-coreutils-mesboot-8.32.drv
> /gnu/store/i584nxkb39n67vzq5r3yh6spqppzrj43-bzip2-mesboot-1.0.8.drv
> /gnu/store/j1accym68y6l8pxz8095jpkwgp3ciphi-gawk-mesboot-3.1.8.drv
> /gnu/store/jlwyxh3k6hvpmy60g0ygwnncq66kn590-gash-utils-boot-0.1.0.drv
> /gnu/store/9mxvccmf0b8fwq0k7lw0ndsdsbz9y8vn-gash-boot-0.2.0.drv
> /gnu/store/p43yklj8d615y68jhcvycg9i3k3bqj2g-xz-mesboot-5.0.0.drv
> /gnu/store/rxn5c166a6p0p3y2hlyk67f91a504kfa-make-mesboot-3.82.drv
> /gnu/store/sgwdni3iwwrb4ahsnwm43528fzr5csiv-sed-mesboot-4.0.6.drv
> /gnu/store/xxaccspqlg90v3cxrbvslva6s8gwxzi9-make-boot0-4.3.drv
> /gnu/store/zghmr1xyw5ip3wpi1qw2ysc7p6i75d54-glibc-mesboot-2.16.0.drv
> /gnu/store/64cway6pvw5fk7csym2k9i77rhp1pl46-coreutils-boot0-8.32.drv
> /gnu/store/7hvyky0i1hf3xbd698rr305br881pwz6-diffutils-boot0-3.7.drv
> /gnu/store/hq1lijdac3vqx811jzsg0wizsbgwgpaa-gawk-boot0-5.1.0.drv
> /gnu/store/i173n23qpssi7idck4jn7399bfkldlfs-sed-boot0-4.8.drv
> /gnu/store/l8kbhm6m9rbwkxn7zv1d06wbl2gi88wp-findutils-boot0-4.8.0.drv
> /gnu/store/pfq7g9jx16jlk3829312h88n0k1jnfns-patch-boot0-2.7.6.drv
> /gnu/store/qp3yg441ybh6bv44lrcxyp6rzyf0djii-file-boot0-5.39.drv
> /gnu/store/x4m7lff1ps5mas719815d54x6x1zwcv3-bzip2-boot0-1.0.8.drv
> /gnu/store/h5hwcnr7z57hb9b8bhhx7s22kfawqr0d-ld-wrapper-boot0-0.drv
> /gnu/store/v9p5fm974mj4d99vdpp9dhrvpwd4kfgs-glibc-2.33.drv
> /gnu/store/0kjyjcxzk5mv6zm86x8f18sbsb9m48k8-bash-static-5.1.8.drv
> /gnu/store/6h220skb9ak8ppv5417i8cbry1byv73a-glibc-intermediate-2.33.drv
> /gnu/store/rwczga96661d70jcqds8w8pr5s084mh4-gcc-cross-boot0-10.3.0.drv

Also, inspecting this gcc-cross-boot0 derivation, I see the following
derivations mentioned in it:

/gnu/store/034y7d9d36986pin4b5plx2ryda1h8i5-glibc-cross-powerpc64le-linux-gnu-2.33.drv
/gnu/store/0gihg5kfh4m09hmc45kwf7kjnv1m84gz-gcc-cross-powerpc64le-linux-gnu-10.3.0.drv
/gnu/store/4ld0jqb2q0di90nizv1vvfngnm39mhln-binutils-cross-powerpc64le-linux-gnu-2.36.1.drv
/gnu/store/m7ddjasnrl290002kql8szh7ahjvl2ir-linux-libre-headers-cross-powerpc64le-linux-gnu-5.10.35.drv

And looking at the gcc-11 build directory, I see:

```
$ find /tmp/guix-build-gcc-11.1.0.drv-0 -name '*.o' -exec file '{}' ';' | cut -d: -f2 | sort | uniq -c
      3  ELF 64-bit LSB relocatable, 64-bit PowerPC or cisco 7500, version 1 (GNU/Linux), with debug_info, not stripped
    235  ELF 64-bit LSB relocatable, 64-bit PowerPC or cisco 7500, version 1 (SYSV), not stripped
   1496  ELF 64-bit LSB relocatable, 64-bit PowerPC or cisco 7500, version 1 (SYSV), with debug_info, not stripped
    118  ELF 64-bit LSB relocatable, x86-64, version 1 (SYSV), not stripped
     14  ELF 64-bit LSB relocatable, x86-64, version 1 (SYSV), with debug_info, not stripped
```

Which is the exact same output I see with the failed gcc-11 build directory
when this patch is applied.

So now I wonder whether these mesboot derivations are just used to bootstrap
x86_64 packages which are then used to build the cross-toolchain, in which
case this patch isn’t actually necessary?

> /gnu/store/cglgsds6hxy9swdyymgam9l3rfwizyfr-libstdc++-boot0-4.9.4.drv
> /gnu/store/c63lqgh0x2rx1az0ds4b2ma9vgiry31j-gcc-11.1.0.drv
> /gnu/store/f4fwnxsha5h2pk750r2p09cnhbhc3nm3-ld-wrapper-0.drv
> /gnu/store/605p0jq8wv879n3y6fbqxvaiww1kjaql-libunistring-0.9.10.drv
> /gnu/store/5irbp0c5zzvs50wlznpfxcxr8mfndwy9-gcc-10.3.0.drv
> /gnu/store/byfbnlkwj9pjwnkx69fi2ycnqdvz2znv-ld-wrapper-boot3-0.drv
> /gnu/store/fbm3gv13nggw2qcvxmlccqgi0izzgdwn-libstdc++-10.3.0.drv
> /gnu/store/vhwmw9p8l3sysqlm8bh14xkfw1afqqcj-zlib-1.2.11.drv
> /gnu/store/60jiv5k1lg2krj3b0f9x7f26ywrda0mw-bash-minimal-5.1.8.drv
> /gnu/store/i0lk6zd2vwqqlhn8kkf0529x896lnzr1-guile-3.0.7.drv
> /gnu/store/r25wjwjbb13yk8yc4bm77dxxcq9qvx9y-libatomic-ops-7.6.10.drv
> /gnu/store/ry3zxxjsnhpdphvnnr991x9yk7gljxy9-libffi-3.3.drv
> /gnu/store/y26kx37mkidni8jj4sjn0ryy1wq1pqvs-libgc-8.0.4.drv
> /gnu/store/v9p5fm974mj4d99vdpp9dhrvpwd4kfgs-glibc-2.33.drv
> --8<---------------cut here---------------end--------------->8---

-- 
Thanks,
Thiago

[bug#49565] [PATCH core-updates v2] gnu: bootstrap: Use %current-target-system to decide bootstrap path

[Thiago Jung Bauermann via Guix-patches via]

Hi again,

Em terça-feira, 20 de julho de 2021, às 10:16:12 -03, Thiago Jung Bauermann 
escreveu:
> Em segunda-feira, 19 de julho de 2021, às 21:01:33 -03,
> 
> Thiago Jung Bauermann escreveu:
> > Before the patch, these are the derivations that Guix tries to build
> > when
> > cross-compiling gcc-toolchain@11. Note the ‘mesboot’ packages:
> One thing I forgot to mention, and which significance only dawned on me
> later: there was a change in Guix behavior between versions of
> core-updates since I posted v1 of this patch.
> 
> Before, I was getting a Guix exception during the build of glibc-mesboot,
> as detailed in the first message in this issue. Now, the mesboot
> packages build fine and the command below goes all the way to the gcc-11
> package just like when this patch is applied.

Now, this is very weird. I tried again with core-updates from today and
I’m back to the original problem in this bug report:

--8<---------------cut here---------------start------------->8---
$ ./pre-inst-env guix build --target=powerpc64le-linux-gnu gcc-toolchain@11
substitute: atualizando substitutos de "https://ci.guix.gnu.org"... 100.0%
substitute: atualizando substitutos de "https://bordeaux.guix.gnu.org"... 100.0%
The following derivations will be built:
   /gnu/store/8p847f47i8b7si24ybcah8936i698v0h-gcc-toolchain-11.1.0.drv
   /gnu/store/2qq0qdrkz6920gyn3xl4ppjqiijf8qh2-ld-wrapper-0.drv
   /gnu/store/59v10rbcl25bcbvgh1xip2k4b8dfrs8s-libatomic-ops-7.6.10.drv
   /gnu/store/2vv32wdv72734d54r85ahlxzddc37gdb-tar-boot0-1.34.drv
   /gnu/store/5h6sjkz0cw5yn77lf2x5i05wina2c2s1-sed-mesboot-4.0.6.drv
   /gnu/store/9baisja0i8z81cpx9bs8dp6bgwbf5hg2-gzip-mesboot-1.2.4.drv
   /gnu/store/aw84y6dbh7av5077dp9cgj3acqwychvs-xz-mesboot-5.0.0.drv
   /gnu/store/d9f9mqjpb0n8fplzplayc5fz9pwvka7f-grep-mesboot-2.0.drv
   /gnu/store/nkmmlizfwvxf1xsyiy2p5wbmxyw2s2kj-make-mesboot-3.82.drv
   /gnu/store/wjmv6b603jd2wfbd43nmlkvlhj5lnwi8-tar-mesboot-1.22.drv
   /gnu/store/xd8bmgimslbaj6gwwllikbqrmcmj4m7b-make-boot0-4.3.drv
   /gnu/store/xnk3pczdfksqhih4qzz1grdj177fasfd-glibc-mesboot-2.16.0.drv
   /gnu/store/y5cpc3sbw8xljd7vck5c77k8qxm1mlb9-patch-mesboot-2.5.9.drv
   /gnu/store/3k1yrgg2qvczabgrnjg1x5gka4slzz6q-glibc-2.33.drv
   /gnu/store/87na4l0i3kxkac9cfdfr267c9n8fg5bp-patch-boot0-2.7.6.drv
   /gnu/store/bpmzfb3mhyr23jxn9mzsivxs1qyprqpp-gcc-cross-boot0-10.3.0.drv
   /gnu/store/dlvzaib6lv85jzs0yifkadfjmm9yg45b-findutils-boot0-4.8.0.drv
   /gnu/store/gbah6yk2pbjl9hjsnd3k72xf7v55149c-diffutils-boot0-3.7.drv
   /gnu/store/ikdrcn12xib71lzsj1dvg0iyv1xn21f1-binutils-cross-boot0-2.36.1.drv
   /gnu/store/n5kz2jyyvd1n361x8fa9p9hndjm302pn-gawk-boot0-5.1.0.drv
   /gnu/store/nxjzb1rnx5f9hfplc3bh4a16i2gqycv3-sed-boot0-4.8.drv
   /gnu/store/qfm8pxwnnlg2s6ck1x2ic1skdbvg3743-bzip2-boot0-1.0.8.drv
   /gnu/store/vbhsj51c26g0wgp1xkjx2dfbbcyz2m9p-file-boot0-5.39.drv
   /gnu/store/zd2gkcb1jmil3q8md33mi03y33hhj0mx-coreutils-boot0-8.32.drv
   /gnu/store/sny8h00brxndd2k2bx867jq7d3x7cdwh-libstdc++-boot0-4.9.4.drv
   /gnu/store/ih5isqwnjpgf9b4nisjyw09xlfdcdm0v-bash-static-5.1.8.drv
   /gnu/store/n94hr5rpx5ihhyicwgxzr73nvd1fbriv-glibc-intermediate-2.33.drv
   /gnu/store/zk5xicfviplfdfqkcxw6pfl6layqj9ai-ld-wrapper-boot0-0.drv
   /gnu/store/7qb2850v8r3lqm2gnj0h8xsmka92ms01-bash-minimal-5.1.8.drv
   /gnu/store/d2rivj2hbqg8z25y82ib4yvygyn84jsf-ld-wrapper-boot3-0.drv
   /gnu/store/hwnfh1c22ysff1j0x1yinil639vpdrjr-binutils-2.36.1.drv
   /gnu/store/h49mll58fg5bqz7n5wv1cq9cf40087ss-gcc-10.3.0.drv
   /gnu/store/3d6cx841pa97g8v30ngrvs9cxyx24ylp-libstdc++-10.3.0.drv
   /gnu/store/qa9znr53yar1z621ay7shvwqrdlymm1h-zlib-1.2.11.drv
   /gnu/store/877vdmhr0jf19q898s7rhr828vsb9jxr-guile-3.0.7.drv
   /gnu/store/dc7fpzizg3ffib0grmg8khm8rvf5ig3p-libunistring-0.9.10.drv
   /gnu/store/h6nrxxs4amnqpqmzdycx3p46dzaygdl8-libgc-8.0.4.drv
   /gnu/store/kch00sjjmn7348vwq9bzzy1q6jyxff3g-libffi-3.3.drv
   /gnu/store/3k1yrgg2qvczabgrnjg1x5gka4slzz6q-glibc-2.33.drv
   /gnu/store/ygky86azk6wgrcswvv9zzv0rglhlmpkf-gcc-11.1.0.drv
   /gnu/store/azfr3647s4frasr208ay7rhdzcqi99jh-libstdc++-headers-10.3.0.drv
   /gnu/store/paysivrjqdai8v69xdxsmpiplj09bpvl-libelf-0.8.13.drv
building /gnu/store/xnk3pczdfksqhih4qzz1grdj177fasfd-glibc-mesboot-2.16.0.drv...
    ⋮
<snip lots of output>
    ⋮
phase `patch-source-shebangs' succeeded after 0.6 seconds
starting phase `setenv'
error: in phase 'setenv': uncaught exception:
wrong-type-arg "string-append" "Wrong type (expecting ~A): ~S" ("string" #f) (#f)
phase `setenv' failed after 0.0 seconds
Backtrace:
In ice-9/boot-9.scm:
 157: 15 [catch #t #<catch-closure c93c40> ...]
In unknown file:
   ?: 14 [apply-smob/1 #<catch-closure c93c40>]
In ice-9/boot-9.scm:
  63: 13 [call-with-prompt prompt0 ...]
In ice-9/eval.scm:
 432: 12 [eval # #]
In ice-9/boot-9.scm:
2320: 11 [save-module-excursion #<procedure cc1b00 at ice-9/boot-9.scm:3961:3 ()>]
3966: 10 [#<procedure cc1b00 at ice-9/boot-9.scm:3961:3 ()>]
1645: 9 [%start-stack load-stack #<procedure cc2ba0 at ice-9/boot-9.scm:3957:10 ()>]
1650: 8 [#<procedure cc8db0 ()>]
In unknown file:
   ?: 7 [primitive-load "/gnu/store/wy882br3mdvkdzc8ql4msbk2qklr8y8h-glibc-mesboot-2.16.0-builder"]
In ice-9/boot-9.scm:
 157: 6 [catch srfi-34 ...]
In srfi/srfi-1.scm:
 616: 5 [for-each #<procedure 1502380 at guix/build/gnu-build-system.scm:909:14 (expr)> ...]
In ice-9/boot-9.scm:
 171: 4 [with-throw-handler #t ...]
In guix/build/gnu-build-system.scm:
 925: 3 [#<procedure 19a1400 at guix/build/gnu-build-system.scm:924:21 ()>]
In ice-9/eval.scm:
 411: 2 [eval # #]
In unknown file:
   ?: 1 [string-append " -L " ...]
In ice-9/boot-9.scm:
 106: 0 [#<procedure 19a13c0 at ice-9/boot-9.scm:97:6 (thrown-k . args)> wrong-type-arg ...]

ice-9/boot-9.scm:106:20: In procedure #<procedure 19a13c0 at ice-9/boot-9.scm:97:6 (thrown-k . args)>:
ice-9/boot-9.scm:106:20: In procedure string-append: Wrong type (expecting string): #f
builder for `/gnu/store/xnk3pczdfksqhih4qzz1grdj177fasfd-glibc-mesboot-2.16.0.drv' failed with exit code 1
build of /gnu/store/xnk3pczdfksqhih4qzz1grdj177fasfd-glibc-mesboot-2.16.0.drv failed
View build log at '/var/log/guix/drvs/xn/k3pczdfksqhih4qzz1grdj177fasfd-glibc-mesboot-2.16.0.drv.bz2'.
cannot build derivation `/gnu/store/ikdrcn12xib71lzsj1dvg0iyv1xn21f1-binutils-cross-boot0-2.36.1.drv': 1 dependencies couldn't be built
--8<---------------cut here---------------end--------------->8---

This is with the following commit:

$ git log --oneline -n1
c3e33474b965 (HEAD -> core-updates, origin/core-updates) gnu: biber: Update to 2.16.

I forgot to mention in my previous email which was the commit that worked.
It’s this one:

$ git log --oneline -n1
b15c3dd9b0e9 (HEAD) gnu: meson: Update to 0.59.0.

I just tested it again, and it does work if I revert back to it.

-- 
Thanks,
Thiago

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

[Ludovic Courtès]

Hi!

Thiago Jung Bauermann <bauermann@kolabnow.com> skribis:

> $ ./pre-inst-env guix build --target=powerpc64le-linux-gnu gcc-toolchain@11
> substitute: atualizando substitutos de "https://ci.guix.gnu.org"... 100.0%
> substitute: atualizando substitutos de "https://bordeaux.guix.gnu.org"... 100.0%
> The following derivations will be built:
>    /gnu/store/8p847f47i8b7si24ybcah8936i698v0h-gcc-toolchain-11.1.0.drv
>    /gnu/store/2qq0qdrkz6920gyn3xl4ppjqiijf8qh2-ld-wrapper-0.drv
>    /gnu/store/59v10rbcl25bcbvgh1xip2k4b8dfrs8s-libatomic-ops-7.6.10.drv
>    /gnu/store/2vv32wdv72734d54r85ahlxzddc37gdb-tar-boot0-1.34.drv
>    /gnu/store/5h6sjkz0cw5yn77lf2x5i05wina2c2s1-sed-mesboot-4.0.6.drv
>    /gnu/store/9baisja0i8z81cpx9bs8dp6bgwbf5hg2-gzip-mesboot-1.2.4.drv
>    /gnu/store/aw84y6dbh7av5077dp9cgj3acqwychvs-xz-mesboot-5.0.0.drv
>    /gnu/store/d9f9mqjpb0n8fplzplayc5fz9pwvka7f-grep-mesboot-2.0.drv

I think you hit a corner with ‘gcc-toolchain’.  The packages in
commencement.scm (*-boot0, *-mesboot, etc.) should never be
cross-compiled; they’re not meant to.  If you find a command that ends
up trying to cross-compile them, it means there’s a problem.

What you want in this case is:

  ./pre-inst-env guix build -e '(@ (gnu packages gcc) gcc-11)' \
     --target=powerpc64le-linux-gnu -n

That is going to build the right thing.

Why is ‘gcc-toolchain’ a special case?  Precisely because it pulls in
things from commencement.scm: ‘binutils-final’, ‘glibc-final’, etc.

And why does it pull these ‘-final’ variants instead of the ‘binutils’,
‘glibc’, etc. you ask?  :-)  That’s to save space; that way, you don’t
end up downloading/building another toolchain when you run
‘guix install gcc-toolchain’.

I hope this clarifies things a bit!

Ludo’.

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

[Thiago Jung Bauermann via Guix-patches via]

Hi Ludo’,

Em quarta-feira, 21 de julho de 2021, às 19:01:07 -03, Ludovic Courtès
escreveu:
> Thiago Jung Bauermann <bauermann@kolabnow.com> skribis:
> > $ ./pre-inst-env guix build --target=powerpc64le-linux-gnu
> > gcc-toolchain@11 substitute: atualizando substitutos de
> > "https://ci.guix.gnu.org"... 100.0% substitute: atualizando
> > substitutos de "https://bordeaux.guix.gnu.org"... 100.0%> 
> > The following derivations will be built:
> >    /gnu/store/8p847f47i8b7si24ybcah8936i698v0h-gcc-toolchain-11.1.0.drv
> >    /gnu/store/2qq0qdrkz6920gyn3xl4ppjqiijf8qh2-ld-wrapper-0.drv
> >    /gnu/store/59v10rbcl25bcbvgh1xip2k4b8dfrs8s-libatomic-ops-7.6.10.drv
> >    /gnu/store/2vv32wdv72734d54r85ahlxzddc37gdb-tar-boot0-1.34.drv
> >    /gnu/store/5h6sjkz0cw5yn77lf2x5i05wina2c2s1-sed-mesboot-4.0.6.drv
> >    /gnu/store/9baisja0i8z81cpx9bs8dp6bgwbf5hg2-gzip-mesboot-1.2.4.drv
> >    /gnu/store/aw84y6dbh7av5077dp9cgj3acqwychvs-xz-mesboot-5.0.0.drv
> >    /gnu/store/d9f9mqjpb0n8fplzplayc5fz9pwvka7f-grep-mesboot-2.0.drv
> 
> I think you hit a corner with ‘gcc-toolchain’.  The packages in
> commencement.scm (*-boot0, *-mesboot, etc.) should never be
> cross-compiled; they’re not meant to.  If you find a command that ends
> up trying to cross-compile them, it means there’s a problem.

My doubt was whether they were being cross-compiled, or Guix was building
them natively as an intermediary step in the path to obtain a
cross-toolchain.

This patch:

https://issues.guix.gnu.org/49565#11

allows gcc-toolchain@11 to be cross-compiled without going through mesboot
packages – or it would if bug 49600 didn’t get in the way. Do you think
it is correct?

> What you want in this case is:
> 
>   ./pre-inst-env guix build -e '(@ (gnu packages gcc) gcc-11)' \
>      --target=powerpc64le-linux-gnu -n
> 
> That is going to build the right thing.

Nice! I should have thought of it.

> Why is ‘gcc-toolchain’ a special case?  Precisely because it pulls in
> things from commencement.scm: ‘binutils-final’, ‘glibc-final’, etc.
> 
> And why does it pull these ‘-final’ variants instead of the ‘binutils’,
> ‘glibc’, etc. you ask?  :-)  That’s to save space; that way, you don’t
> end up downloading/building another toolchain when you run
> ‘guix install gcc-toolchain’.
> 
> I hope this clarifies things a bit!

It does! Thank you very much for these clarifications. The pieces are still
falling into place in my mind.

-- 
Thanks,
Thiago