[Top][All Lists]

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

[bug#49565] [PATCH core-updates] gnu: bootstrap: Use %current-target-sys

From: Thiago Jung Bauermann
Subject: [bug#49565] [PATCH core-updates] gnu: bootstrap: Use %current-target-system to decide bootstrap path
Date: Fri, 16 Jul 2021 17:01:09 -0300


Em sexta-feira, 16 de julho de 2021, às 05:20:20 -03, Maxime Devos
> 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 \
<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 
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.


reply via email to

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