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

  • Open
  • quality assurance status badge
Details
3 participants
  • Thiago Jung Bauermann
  • Ludovic Courtès
  • Maxime Devos
Owner
unassigned
Submitted by
Thiago Jung Bauermann
Severity
normal
T
T
Thiago Jung Bauermann wrote on 15 Jul 2021 02:46
(address . guix-patches@gnu.org)(name . Thiago Jung Bauermann)(address . bauermann@kolabnow.com)
20210715004613.763843-1-bauermann@kolabnow.com
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:

Toggle snippet (44 lines)
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

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.

Toggle diff (19 lines)
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"))
T
T
Thiago Jung Bauermann wrote on 15 Jul 2021 04:04
(address . 49565@debbugs.gnu.org)
7964923.2P2ymJy1PT@popigai
Em quarta-feira, 14 de julho de 2021, às 21:46:13 -03, Thiago Jung
Bauermann escreveu:
Toggle quote (8 lines)
> 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
M
M
Maxime Devos wrote on 15 Jul 2021 14:58
Re: [bug#49565] [PATCH] gnu: glibc-headers-mesboot: Use %build-inputs in setenv phase
0eac02a304064759c0bbe37f91ece93ebd6f0994.camel@telenet.be
Hi,

Thiago Jung Bauermann via Guix-patches via schreef op wo 14-07-2021 om 21:46 [-0300]:
Toggle quote (20 lines)
> 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.

Toggle quote (3 lines)
> 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).

Toggle quote (8 lines)
> 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?

Toggle quote (20 lines)
> 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.
-----BEGIN PGP SIGNATURE-----

iI0EABYKADUWIQTB8z7iDFKP233XAR9J4+4iGRcl7gUCYPAxAxccbWF4aW1lZGV2
b3NAdGVsZW5ldC5iZQAKCRBJ4+4iGRcl7qq3AP9bXiSrd5Ol1luc0lvY7W9hS60b
XwETgGCdXtR3Mf+PwAEA3WfZIN9bTo8ZHstsURxDAKJU7ifoiHq+oqZUZGXrdg4=
=HDQb
-----END PGP SIGNATURE-----


T
T
Thiago Jung Bauermann wrote on 15 Jul 2021 17:03
4491449.dtmGtMj3lj@popigai
Hello Maxime,

Thanks for your help.

Em quinta-feira, 15 de julho de 2021, às 09:58:54 -03, Maxime Devos
escreveu:
Toggle quote (1 lines)
> Thiago Jung Bauermann via Guix-patches via schreef op wo 14-07-2021 om
21:46 [-0300]:
Toggle quote (30 lines)
> > 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:


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.

Toggle quote (7 lines)
> > 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.

Toggle quote (24 lines)
> > 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.

Toggle quote (3 lines)
> 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.

Toggle quote (4 lines)
> 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
M
M
Maxime Devos wrote on 15 Jul 2021 18:00
b01a587c2b7bf584beac14f3b9ce97765fd24c94.camel@telenet.be
Toggle quote (12 lines)
> [...]
>
> > 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.
-----BEGIN PGP SIGNATURE-----

iI0EABYKADUWIQTB8z7iDFKP233XAR9J4+4iGRcl7gUCYPBbqRccbWF4aW1lZGV2
b3NAdGVsZW5ldC5iZQAKCRBJ4+4iGRcl7hvBAP9bGudvok9wmQ//ODQIy7bnbfwJ
2GPYp6jXCJyWIjcc3gD8DWWLYx6lIGhwbC/JDg31++9IOiPY5ApGmfAMTfAH2g8=
=aJWa
-----END PGP SIGNATURE-----


T
T
Thiago Jung Bauermann wrote on 15 Jul 2021 19:02
11392919.zUUP5XLHND@popigai
Em quinta-feira, 15 de julho de 2021, às 13:00:41 -03, Maxime Devos
escreveu:
Toggle quote (45 lines)
> > [...]
> >
> > > 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:

Toggle snippet (56 lines)
$ ./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

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
T
T
Thiago Jung Bauermann wrote on 16 Jul 2021 03:31
[PATCH core-updates] gnu: bootstrap: Use %current-target-system to decide bootstrap path
(address . 49565@debbugs.gnu.org)(name . Thiago Jung Bauermann)(address . bauermann@kolabnow.com)
20210716013143.901859-1-bauermann@kolabnow.com
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:


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:

Toggle snippet (43 lines)
$ ./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


Toggle diff (26 lines)
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))
(_
M
M
Maxime Devos wrote on 16 Jul 2021 10:20
27e26df84bc02d681b1ff0904bdd63dfa80313bf.camel@telenet.be
Hi,


Toggle quote (14 lines)
> 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.
-----BEGIN PGP SIGNATURE-----

iI0EABYKADUWIQTB8z7iDFKP233XAR9J4+4iGRcl7gUCYPFBPRccbWF4aW1lZGV2
b3NAdGVsZW5ldC5iZQAKCRBJ4+4iGRcl7qgKAQCoQB+qOHmHc6pFWT5Go+sH8Yyq
rIjWxUtwKcfhAPfjIwEAirtV1BbavnJOBqzsZSBvCp4ogwdHKa0OWyGKLv+1RwE=
=J+4B
-----END PGP SIGNATURE-----


T
T
Thiago Jung Bauermann wrote on 16 Jul 2021 22:01
38562486.AUsm6asf6Y@popigai
Hello,

Em sexta-feira, 16 de julho de 2021, às 05:20:20 -03, Maxime Devos
escreveu:
Toggle quote (30 lines)
> 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.

Toggle quote (5 lines)
> 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:

Toggle snippet (28 lines)
$ ./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

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
T
T
Thiago Jung Bauermann wrote on 18 Jul 2021 18:45
4729414.XUdnh1gNuZ@popigai
Em domingo, 18 de julho de 2021, às 13:10:40 -03, Maxime Devos escreveu:
Toggle quote (17 lines)
> 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.

Toggle quote (14 lines)
> > 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
M
M
Maxime Devos wrote on 18 Jul 2021 18:10
55865ae75130bb06154c5cf68ad8f3a89c511515.camel@telenet.be
Thiago Jung Bauermann schreef op vr 16-07-2021 om 17:01 [-0300]:
Toggle quote (9 lines)
> 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).

Toggle quote (8 lines)
> 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.

Toggle quote (4 lines)
> 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.
-----BEGIN PGP SIGNATURE-----

iI0EABYKADUWIQTB8z7iDFKP233XAR9J4+4iGRcl7gUCYPRSgRccbWF4aW1lZGV2
b3NAdGVsZW5ldC5iZQAKCRBJ4+4iGRcl7uzjAP9y3MFsqg8w4zKSh0Gh4vFBpmU2
LS44wHXBuGcAfQ4zFAD+O0gg1QeAT2Dl4xJMCvtCoy3akeDclrLd0h8uiy2scQk=
=vIYt
-----END PGP SIGNATURE-----


T
T
Thiago Jung Bauermann wrote on 20 Jul 2021 02:01
[PATCH core-updates v2] gnu: bootstrap: Use %current-target-system to decide bootstrap path
(address . 49565@debbugs.gnu.org)
20210720000133.1619640-1-bauermann@kolabnow.com
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:

Toggle snippet (55 lines)
$ ./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

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

Toggle snippet (38 lines)
$ ./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

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

db5962c68099 gnu: ghostscript: Improve reproducibility of PDF document generation

Toggle diff (71 lines)
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\"
T
T
Thiago Jung Bauermann wrote on 20 Jul 2021 15:16
(address . 49565@debbugs.gnu.org)(name . Maxime Devos)(address . maximedevos@telenet.be)
10364598.u94UDZUMEq@popigai
Hello,

Em segunda-feira, 19 de julho de 2021, às 21:01:33 -03,
Thiago Jung Bauermann escreveu:
Toggle quote (3 lines)
> 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.

Toggle quote (41 lines)
> --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?

Toggle quote (16 lines)
> /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
T
T
Thiago Jung Bauermann wrote on 21 Jul 2021 22:30
(address . 49565@debbugs.gnu.org)(name . Maxime Devos)(address . maximedevos@telenet.be)
12914341.VykQ5r6Z2s@popigai
Hi again,

Em terça-feira, 20 de julho de 2021, às 10:16:12 -03, Thiago Jung Bauermann
escreveu:
Toggle quote (15 lines)
> 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:

Toggle snippet (94 lines)
$ ./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

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
L
L
Ludovic Courtès wrote on 22 Jul 2021 00:01
Re: bug#49565: [PATCH] gnu: glibc-headers-mesboot: Use %build-inputs in setenv phase
(name . Thiago Jung Bauermann)(address . bauermann@kolabnow.com)
87k0lje38c.fsf_-_@gnu.org
Hi!

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

Toggle quote (13 lines)
> $ ./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’.
T
T
Thiago Jung Bauermann wrote on 22 Jul 2021 02:32
(name . Ludovic Courtès)(address . ludo@gnu.org)
2955097.dfWu6T0S3y@popigai
Hi Ludo’,

Em quarta-feira, 21 de julho de 2021, às 19:01:07 -03, Ludovic Courtès
escreveu:
Toggle quote (20 lines)
> 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:


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?

Toggle quote (7 lines)
> 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.

Toggle quote (10 lines)
> 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
?
Your comment

Commenting via the web interface is currently disabled.

To comment on this conversation send an email to 49565@debbugs.gnu.org

To respond to this issue using the mumi CLI, first switch to it
mumi current 49565
Then, you may apply the latest patchset in this issue (with sign off)
mumi am -- -s
Or, compose a reply to this issue
mumi compose
Or, send patches to this issue
mumi send-email *.patch