| Message ID | 20210715004613.763843-1-bauermann@kolabnow.com |
|---|---|
| State | New |
| Headers | show |
| Series | [bug#49565] gnu: glibc-headers-mesboot: Use %build-inputs in setenv phase | expand |
| Context | Check | Description |
|---|---|---|
| cbaines/applying patch | fail | View Laminar job |
| cbaines/issue | success | View issue |
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. :-)
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.
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.
> [...] > > > 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.
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.
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"))