Freezing core-updates

Freezing core-updates

[Ludovic Courtès]

Hello Guix!

I hereby declare ‘core-updates’ frozen!  :-)

That is, we should now work towards fixing the “core” packages, then make
Hydra build everything, fix packages, and finally merge it.  I invite
you all to spend a bit of time on it, it’s fun and profitable.  :-)

Currently, the main problem is a frightening GCC 5.3 build issue on ARM:
<https://hydra.gnu.org/build/1201428/nixlog/1/tail-reload>:

--8<---------------cut here---------------start------------->8---
make[3]: Leaving directory '/tmp/nix-build-gcc-5.3.0.drv-0/build'
Comparing stages 2 and 3
warning: gcc/cc1plus-checksum.o differs
warning: gcc/cc1-checksum.o differs
Bootstrap comparison failure!
gcc/fold-const.o differs
gcc/cp/semantics.o differs
gcc/cp/optimize.o differs
gcc/dwarf2cfi.o differs
gcc/tree-ssa-sccvn.o differs
gcc/real.o differs
gcc/libgcov-driver-tool.o differs
gcc/tree-nested.o differs
gcc/lto-section-out.o differs
gcc/c/c-typeck.o differs
gcc/c/c-parser.o differs
gcc/lto-streamer-out.o differs
gcc/tree-dfa.o differs
gcc/ipa-inline.o differs
gcc/c-family/cilk.o differs
gcc/gcov-dump.o differs
gcc/coverage.o differs
gcc/tree-inline.o differs
gcc/omp-low.o differs
gcc/double-int.o differs
gcc/tree-ssa-math-opts.o differs
gcc/simplify-rtx.o differs
gcc/df-scan.o differs
gcc/tree-switch-conversion.o differs
libiberty/fibheap.o differs
libiberty/simple-object-xcoff.o differs
libiberty/sort.o differs
libiberty/pic/fibheap.o differs
libiberty/pic/simple-object-xcoff.o differs
libiberty/pic/sort.o differs
Makefile:21400: recipe for target 'compare' failed
make[2]: *** [compare] Error 1
--8<---------------cut here---------------end--------------->8---

Can someone with an ARM machine reproduce it?  I wonder if it could be a
hardware failure.

See <https://hydra.gnu.org/jobset/gnu/core-updates> for more.

Ludo’.

Re: Freezing core-updates

[Leo Famulari]

Oh, I was just working on yesterday's new release of tar (1.29). I guess it will wait for the next cycle?

Sorry for the top-post...


-------- Original Message --------
From: ludo@gnu.org
Sent: May 17, 2016 4:59:41 AM EDT
To: Guix-devel <guix-devel@gnu.org>
Subject: Freezing core-updates

Hello Guix!

I hereby declare ‘core-updates’ frozen!  :-)

That is, we should now work towards fixing the “core” packages, then make
Hydra build everything, fix packages, and finally merge it.  I invite
you all to spend a bit of time on it, it’s fun and profitable.  :-)

Currently, the main problem is a frightening GCC 5.3 build issue on ARM:
<https://hydra.gnu.org/build/1201428/nixlog/1/tail-reload>:

--8<---------------cut here---------------start------------->8---
make[3]: Leaving directory '/tmp/nix-build-gcc-5.3.0.drv-0/build'
Comparing stages 2 and 3
warning: gcc/cc1plus-checksum.o differs
warning: gcc/cc1-checksum.o differs
Bootstrap comparison failure!
gcc/fold-const.o differs
gcc/cp/semantics.o differs
gcc/cp/optimize.o differs
gcc/dwarf2cfi.o differs
gcc/tree-ssa-sccvn.o differs
gcc/real.o differs
gcc/libgcov-driver-tool.o differs
gcc/tree-nested.o differs
gcc/lto-section-out.o differs
gcc/c/c-typeck.o differs
gcc/c/c-parser.o differs
gcc/lto-streamer-out.o differs
gcc/tree-dfa.o differs
gcc/ipa-inline.o differs
gcc/c-family/cilk.o differs
gcc/gcov-dump.o differs
gcc/coverage.o differs
gcc/tree-inline.o differs
gcc/omp-low.o differs
gcc/double-int.o differs
gcc/tree-ssa-math-opts.o differs
gcc/simplify-rtx.o differs
gcc/df-scan.o differs
gcc/tree-switch-conversion.o differs
libiberty/fibheap.o differs
libiberty/simple-object-xcoff.o differs
libiberty/sort.o differs
libiberty/pic/fibheap.o differs
libiberty/pic/simple-object-xcoff.o differs
libiberty/pic/sort.o differs
Makefile:21400: recipe for target 'compare' failed
make[2]: *** [compare] Error 1
--8<---------------cut here---------------end--------------->8---

Can someone with an ARM machine reproduce it?  I wonder if it could be a
hardware failure.

See <https://hydra.gnu.org/jobset/gnu/core-updates> for more.

Ludo’.

Re: Freezing core-updates

[Ludovic Courtès]

Leo Famulari <leo@famulari.name> skribis:

> Oh, I was just working on yesterday's new release of tar (1.29). I guess it will wait for the next cycle?

I updated it earlier today, as discussed on IRC, so everything’s
alright.  :-)

Thanks,
Ludo’.

Re: Freezing core-updates

[Leo Famulari]

On Tue, May 17, 2016 at 07:29:19AM -0400, Leo Famulari wrote:
> Oh, I was just working on yesterday's new release of tar (1.29). I guess it will wait for the next cycle?

Please disregard. I see you've added it already :)

Re: Freezing core-updates

[Matthew Jordan]

Hi Ludovic Courtès,

Just to clear does this mean any new package submissions are now be put on hold?

Respectfully,

-- 
Matthew Jordan
Sent with my mu4e

Ludovic Courtès writes:

> Hello Guix!
>
> I hereby declare ‘core-updates’ frozen!  :-)
>
> That is, we should now work towards fixing the “core” packages, then make
> Hydra build everything, fix packages, and finally merge it.  I invite
> you all to spend a bit of time on it, it’s fun and profitable.  :-)
>
> Currently, the main problem is a frightening GCC 5.3 build issue on ARM:
> <https://hydra.gnu.org/build/1201428/nixlog/1/tail-reload>:
>
> --8<---------------cut here---------------start------------->8---
> make[3]: Leaving directory '/tmp/nix-build-gcc-5.3.0.drv-0/build'
> Comparing stages 2 and 3
> warning: gcc/cc1plus-checksum.o differs
> warning: gcc/cc1-checksum.o differs
> Bootstrap comparison failure!
> gcc/fold-const.o differs
> gcc/cp/semantics.o differs
> gcc/cp/optimize.o differs
> gcc/dwarf2cfi.o differs
> gcc/tree-ssa-sccvn.o differs
> gcc/real.o differs
> gcc/libgcov-driver-tool.o differs
> gcc/tree-nested.o differs
> gcc/lto-section-out.o differs
> gcc/c/c-typeck.o differs
> gcc/c/c-parser.o differs
> gcc/lto-streamer-out.o differs
> gcc/tree-dfa.o differs
> gcc/ipa-inline.o differs
> gcc/c-family/cilk.o differs
> gcc/gcov-dump.o differs
> gcc/coverage.o differs
> gcc/tree-inline.o differs
> gcc/omp-low.o differs
> gcc/double-int.o differs
> gcc/tree-ssa-math-opts.o differs
> gcc/simplify-rtx.o differs
> gcc/df-scan.o differs
> gcc/tree-switch-conversion.o differs
> libiberty/fibheap.o differs
> libiberty/simple-object-xcoff.o differs
> libiberty/sort.o differs
> libiberty/pic/fibheap.o differs
> libiberty/pic/simple-object-xcoff.o differs
> libiberty/pic/sort.o differs
> Makefile:21400: recipe for target 'compare' failed
> make[2]: *** [compare] Error 1
> --8<---------------cut here---------------end--------------->8---
>
> Can someone with an ARM machine reproduce it?  I wonder if it could be a
> hardware failure.
>
> See <https://hydra.gnu.org/jobset/gnu/core-updates> for more.
>
> Ludo’.

Re: Freezing core-updates

[Ben Woodcroft]

Hi Matthew,

On 17/05/16 22:03, Matthew Jordan wrote:
> Hi Ludovic Courtès,
>
> Just to clear does this mean any new package submissions are now be put on hold?

Not at all, keep them coming.

Core-updates is a branch of the repository where packages that affect 
many others are updated (e.g. boost) because they trigger large numbers 
of rebuilds. In contrast, most new packages are applied to the 'master' 
branch, which isn't frozen.

ben

Re: Freezing core-updates

[Ludovic Courtès]

Hello!

Matthew Jordan <matthewjordandevops@yandex.com> skribis:

> Just to clear does this mean any new package submissions are now be put on hold?

No, not at all.  It’s just rebuild-the-world changes (those that go to
the ‘core-updates’ branch) that are put on hold.

Thanks,
Ludo’.

Re: Freezing core-updates

[Andreas Enge]

On Tue, May 17, 2016 at 10:59:41AM +0200, Ludovic Courtès wrote:
> Currently, the main problem is a frightening GCC 5.3 build issue on ARM:
> <https://hydra.gnu.org/build/1201428/nixlog/1/tail-reload>:
> 
> --8<---------------cut here---------------start------------->8---
> make[3]: Leaving directory '/tmp/nix-build-gcc-5.3.0.drv-0/build'
> Comparing stages 2 and 3
> ...
> libiberty/pic/sort.o differs
> Makefile:21400: recipe for target 'compare' failed
> make[2]: *** [compare] Error 1
> --8<---------------cut here---------------end--------------->8---
> 
> Can someone with an ARM machine reproduce it?  I wonder if it could be a
> hardware failure.

I tried it on solar, which is not part of the hydra build farm, and it failed
similarly (I did not check the exact list of different files). So it does
not look like a hardware failure.

Andreas

Re: Freezing core-updates

[Ludovic Courtès]

Andreas Enge <andreas@enge.fr> skribis:

> On Tue, May 17, 2016 at 10:59:41AM +0200, Ludovic Courtès wrote:
>> Currently, the main problem is a frightening GCC 5.3 build issue on ARM:
>> <https://hydra.gnu.org/build/1201428/nixlog/1/tail-reload>:
>> 
>> --8<---------------cut here---------------start------------->8---
>> make[3]: Leaving directory '/tmp/nix-build-gcc-5.3.0.drv-0/build'
>> Comparing stages 2 and 3
>> ...
>> libiberty/pic/sort.o differs
>> Makefile:21400: recipe for target 'compare' failed
>> make[2]: *** [compare] Error 1
>> --8<---------------cut here---------------end--------------->8---
>> 
>> Can someone with an ARM machine reproduce it?  I wonder if it could be a
>> hardware failure.
>
> I tried it on solar, which is not part of the hydra build farm, and it failed
> similarly (I did not check the exact list of different files). So it does
> not look like a hardware failure.

Bad news.  :-/

Could you save the offending .o files that are listed and upload them
somewhere, or run diffoscope on them?

Thanks for testing!

Ludo’.

Re: Freezing core-updates

[Andreas Enge]

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

On Sat, May 28, 2016 at 05:25:35PM +0200, Ludovic Courtès wrote:
> Could you save the offending .o files that are listed and upload them
> somewhere, or run diffoscope on them?

Of course the first time I forgot to add the "-K" parameter. So I redid the
build and saved the build tree. Here is the error message:
Comparing stages 2 and 3
warning: gcc/cc1plus-checksum.o differs
warning: gcc/cc1-checksum.o differs
Bootstrap comparison failure!
gcc/libgcov-driver-tool.o differs
gcc/tree-nested.o differs
gcc/df-scan.o differs
gcc/double-int.o differs
gcc/simplify-rtx.o differs
gcc/c/c-parser.o differs
gcc/c/c-typeck.o differs
gcc/gcov-dump.o differs
gcc/tree-ssa-math-opts.o differs
gcc/fold-const.o differs
gcc/cp/semantics.o differs
gcc/cp/optimize.o differs
gcc/tree-dfa.o differs
gcc/tree-inline.o differs
gcc/c-family/cilk.o differs
gcc/ipa-inline.o differs
gcc/lto-section-out.o differs
gcc/omp-low.o differs
gcc/tree-switch-conversion.o differs
gcc/lto-streamer-out.o differs
gcc/real.o differs
gcc/tree-ssa-sccvn.o differs
gcc/coverage.o differs
gcc/dwarf2cfi.o differs
libiberty/pic/sort.o differs
libiberty/pic/fibheap.o differs
libiberty/pic/simple-object-xcoff.o differs
libiberty/sort.o differs
libiberty/fibheap.o differs
libiberty/simple-object-xcoff.o differs
Makefile:21400: recipe for target 'compare' failed

Things do not look good. I am attaching one pair of differing object files.
Already their file size is radically different! The same holds for a few
other pairs of files I had a look at.

Andreas


[-- Attachment #2: real.o --]
[-- Type: application/octet-stream, Size: 361036 bytes --]

[-- Attachment #3: real.o --]
[-- Type: application/octet-stream, Size: 43016 bytes --]

Re: Freezing core-updates

[Ludovic Courtès]

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

Andreas Enge <andreas@enge.fr> skribis:

> Of course the first time I forgot to add the "-K" parameter. So I redid the
> build and saved the build tree. Here is the error message:
> Comparing stages 2 and 3
> warning: gcc/cc1plus-checksum.o differs
> warning: gcc/cc1-checksum.o differs
> Bootstrap comparison failure!
> gcc/libgcov-driver-tool.o differs
> gcc/tree-nested.o differs
> gcc/df-scan.o differs
> gcc/double-int.o differs
> gcc/simplify-rtx.o differs
> gcc/c/c-parser.o differs
> gcc/c/c-typeck.o differs
> gcc/gcov-dump.o differs
> gcc/tree-ssa-math-opts.o differs
> gcc/fold-const.o differs
> gcc/cp/semantics.o differs
> gcc/cp/optimize.o differs
> gcc/tree-dfa.o differs
> gcc/tree-inline.o differs
> gcc/c-family/cilk.o differs
> gcc/ipa-inline.o differs
> gcc/lto-section-out.o differs
> gcc/omp-low.o differs
> gcc/tree-switch-conversion.o differs
> gcc/lto-streamer-out.o differs
> gcc/real.o differs
> gcc/tree-ssa-sccvn.o differs
> gcc/coverage.o differs
> gcc/dwarf2cfi.o differs
> libiberty/pic/sort.o differs
> libiberty/pic/fibheap.o differs
> libiberty/pic/simple-object-xcoff.o differs
> libiberty/sort.o differs
> libiberty/fibheap.o differs
> libiberty/simple-object-xcoff.o differs
> Makefile:21400: recipe for target 'compare' failed
>
> Things do not look good. I am attaching one pair of differing object files.
> Already their file size is radically different! The same holds for a few
> other pairs of files I had a look at.

Quick observation: one of the file has debugging symbols, the other not.
Apart from that, section sizes are very similar:

--8<---------------cut here---------------start------------->8---
$ ls -l o1 o2
-rw------- 1 ludo users 361036 May 31 23:14 o1
-rw------- 1 ludo users  43016 May 31 23:14 o2
$ size o1 o2
   text	   data	    bss	    dec	    hex	filename
  22172	      0	   1560	  23732	   5cb4	o1
  22156	      0	   1560	  23716	   5ca4	o2
$ objdump -h o1

o1:     file format elf32-little

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  0 .text         00004a10  00000000  00000000  00000038  2**3
                  CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE
  1 .data         00000000  00000000  00000000  00004a48  2**0
                  CONTENTS, ALLOC, LOAD, DATA
  2 .bss          00000618  00000000  00000000  00004a48  2**2
                  ALLOC
  3 .ARM.extab    00000084  00000000  00000000  00004a48  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  4 .ARM.exidx    00000358  00000000  00000000  00004acc  2**2
                  CONTENTS, ALLOC, LOAD, RELOC, READONLY, DATA
  5 .rodata       000006a8  00000000  00000000  00004e24  2**2
                  CONTENTS, ALLOC, LOAD, RELOC, READONLY, DATA
  6 .rodata.str1.4 00000208  00000000  00000000  000054cc  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  7 .debug_info   000171e4  00000000  00000000  000056d4  2**0
                  CONTENTS, RELOC, READONLY, DEBUGGING
  8 .debug_abbrev 00000b44  00000000  00000000  0001c8b8  2**0
                  CONTENTS, READONLY, DEBUGGING
  9 .debug_loc    0000bb96  00000000  00000000  0001d3fc  2**0
                  CONTENTS, RELOC, READONLY, DEBUGGING
 10 .debug_aranges 00000020  00000000  00000000  00028f92  2**0
                  CONTENTS, RELOC, READONLY, DEBUGGING
 11 .debug_ranges 00001438  00000000  00000000  00028fb2  2**0
                  CONTENTS, READONLY, DEBUGGING
 12 .debug_line   000021c5  00000000  00000000  0002a3ea  2**0
                  CONTENTS, RELOC, READONLY, DEBUGGING
 13 .debug_str    00016d9a  00000000  00000000  0002c5af  2**0
                  CONTENTS, READONLY, DEBUGGING
 14 .comment      00000012  00000000  00000000  00043349  2**0
                  CONTENTS, READONLY
 15 .note.GNU-stack 00000000  00000000  00000000  0004335b  2**0
                  CONTENTS, READONLY
 16 .debug_frame  00000ebc  00000000  00000000  0004335c  2**2
                  CONTENTS, RELOC, READONLY, DEBUGGING
 17 .ARM.attributes 00000035  00000000  00000000  00044218  2**0
                  CONTENTS, READONLY
$ objdump -h o2

o2:     file format elf32-little

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  0 .text         00004a00  00000000  00000000  00000038  2**3
                  CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE
  1 .data         00000000  00000000  00000000  00004a38  2**0
                  CONTENTS, ALLOC, LOAD, DATA
  2 .bss          00000618  00000000  00000000  00004a38  2**2
                  ALLOC
  3 .ARM.extab    00000084  00000000  00000000  00004a38  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  4 .ARM.exidx    00000358  00000000  00000000  00004abc  2**2
                  CONTENTS, ALLOC, LOAD, RELOC, READONLY, DATA
  5 .rodata       000006a8  00000000  00000000  00004e14  2**2
                  CONTENTS, ALLOC, LOAD, RELOC, READONLY, DATA
  6 .rodata.str1.4 00000208  00000000  00000000  000054bc  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  7 .comment      00000012  00000000  00000000  000056c4  2**0
                  CONTENTS, READONLY
  8 .note.GNU-stack 00000000  00000000  00000000  000056d6  2**0
                  CONTENTS, READONLY
  9 .ARM.attributes 00000035  00000000  00000000  000056d6  2**0
                  CONTENTS, READONLY
--8<---------------cut here---------------end--------------->8---

Indeed, if we strip it a bit, we get very close:

--8<---------------cut here---------------start------------->8---
$ guix build -e '((@@ (gnu packages cross-base) cross-binutils) "arm-linux-gnueabihf")'
/gnu/store/w7rk1qamh9ws40s6wg148i108229r6fr-binutils-cross-arm-linux-gnueabihf-2.25.1
$ /gnu/store/w7rk1qamh9ws40s6wg148i108229r6fr-binutils-cross-arm-linux-gnueabihf-2.25.1/bin/arm-linux-gnueabihf-strip --strip-debug -o o3 o1
$ ls -l o3 o2
-rw------- 1 ludo users 43016 May 31 23:14 o2
-rw-r--r-- 1 ludo users 43008 May 31 23:26 o3
$ size o3 o2
   text	   data	    bss	    dec	    hex	filename
  22172	      0	   1560	  23732	   5cb4	o3
  22156	      0	   1560	  23716	   5ca4	o2
--8<---------------cut here---------------end--------------->8---

We still have those 16 extra bytes though.

We can disassemble like Diffoscope would do (if it knew about
cross-compilation…):

--8<---------------cut here---------------start------------->8---
$ /gnu/store/w7rk1qamh9ws40s6wg148i108229r6fr-binutils-cross-arm-linux-gnueabihf-2.25.1/bin/arm-linux-gnueabihf-objdump --line-numbers --disassemble --section=.text o3 > a3
$ /gnu/store/w7rk1qamh9ws40s6wg148i108229r6fr-binutils-cross-arm-linux-gnueabihf-2.25.1/bin/arm-linux-gnueabihf-objdump
--line-numbers --disassemble --section=.text o2 > a2
--8<---------------cut here---------------end--------------->8---

… and then compare the assembly, which gives many things like:


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Type: text/x-patch, Size: 518 bytes --]

 Disassembly of section .text:
@@ -425,7 +425,7 @@ _ZL18encode_ieee_doublePK11real_formatPl
      442:	e7af      	b.n	3a4 <_ZL18encode_ieee_doublePK11real_formatPlPK10real_value+0x2c>
      444:	f063 4300 	orn	r3, r3, #2147483648	; 0x80000000
      448:	f04f 35ff 	mov.w	r5, #4294967295	; 0xffffffff
-     44c:	e7aa      	b.n	ffffff58 <_Z29HONOR_SIGN_DEPENDENT_ROUNDINGPK7rtx_def+0xffffb564>
+     44c:	e7aa      	b.n	ffffff58 <_Z29HONOR_SIGN_DEPENDENT_ROUNDINGPK7rtx_def+0xffffb554>
      44e:	f240 0000 	movw	r0, #0

[-- Attachment #3: Type: text/plain, Size: 304 bytes --]


(Note the 16-byte difference in the target address.)

Then we see more significant differences in
_ZL16round_for_formatPK11real_formatP10r, which is probably where the
extra bytes are.

We should check the build log for the command lines used to build
real.o.

To be continued…

Ludo’.

Re: Freezing core-updates

[Andreas Enge]

On Tue, May 31, 2016 at 11:36:21PM +0200, Ludovic Courtès wrote:
> Quick observation: one of the file has debugging symbols, the other not.
> Apart from that, section sizes are very similar:

That is understandable, the debugging symbols come from stage 2, the files
without from stage 3.


To check for an easy work-around, I tested to upgrade the standard gcc
from 5.3 to 6.1. But this fails as follows:

setenv.c: In function '__unsetenv':
setenv.c:279:6: error: suggest explicit braces to avoid ambiguous 'else' [-Werror=parentheses]
   if (ep != NULL)
      ^
cc1: all warnings being treated as errors
../o-iterator.mk:9: recipe for target '/tmp/guix-build-glibc-intermediate-2.23.drv-0/build/stdlib/setenv.o' failed
make[2]: *** [/tmp/guix-build-glibc-intermediate-2.23.drv-0/build/stdlib/setenv.o] Error 1
make[2]: Leaving directory '/tmp/guix-build-glibc-intermediate-2.23.drv-0/glibc-2.23/stdlib'
Makefile:214: recipe for target 'stdlib/subdir_lib' failed
make[1]: *** [stdlib/subdir_lib] Error 2
make[1]: Leaving directory '/tmp/guix-build-glibc-intermediate-2.23.drv-0/glibc-2.23'
Makefile:9: recipe for target 'all' failed
make: *** [all] Error 2
phase `build' failed after 350.8 seconds
builder for `/gnu/store/ja64ppaspnvx5q1a9nlfa0n3hp9kb2p1-glibc-intermediate-2.23.drv' failed with exit code 1
@ build-failed /gnu/store/ja64ppaspnvx5q1a9nlfa0n3hp9kb2p1-glibc-intermediate-2.23.drv - 1 builder for `/gnu/store/ja64ppaspnvx5q1a9nlfa0n3hp9kb2p1-glibc-intermediate-2.23.drv' failed with exit code 1
cannot build derivation `/gnu/store/cnd7vjf59wkvma15zicdv9gg8hl084q7-bash-static-4.3.42.drv': 1 dependencies couldn't be built
cannot build derivation `/gnu/store/p8fsvdqby0api3fhpjk8fg7szv8xqdbn-gcc-6.1.0.drv': 1 dependencies couldn't be built
cannot build derivation `/gnu/store/x34g9mhwn0ssqxfp3w0gy1dnwacm5dh1-gcc-6.1.0.drv': 1 dependencies couldn't be built
cannot build derivation `/gnu/store/7xvr4q068i3h49sad9wab3fbpfgivbn9-glibc-2.23.drv': 1 dependencies couldn't be built
cannot build derivation `/gnu/store/ln53k3lix5421ykvhh8k0pnjbg81f1yi-hello-2.10.drv': 1 dependencies couldn't be built
guix build: error: build failed: build of `/gnu/store/ln53k3lix5421ykvhh8k0pnjbg81f1yi-hello-2.10.drv' failed

Maybe "all warnings treated as errors" is a bit exaggerated here, but in any
case, upgrading gcc is not an easy fix.

> We should check the build log for the command lines used to build
> real.o.

I find this:
105038:libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I../../../gcc-5.3.0/mpc/src -I.. -I/tmp/guix-build-gcc-5.3.0.drv-0/build/./gmp -I/tmp/guix-build-gcc-5.3.0.drv-0/gcc-5.3.0/mpfr/src -g -MT real.lo -MD -MP -MF .deps/real.Tpo -c ../../../gcc-5.3.0/mpc/src/real.c -o real.o
115976:libtool: compile:  /tmp/guix-build-gcc-5.3.0.drv-0/build/./prev-gcc/xgcc -B/tmp/guix-build-gcc-5.3.0.drv-0/build/./prev-gcc/ -B/gnu/store/6xdd64b8343v9vd3nkhkkqg7mayyxvwp-gcc-5.3.0/arm-unknown-linux-gnueabihf/bin/ -B/gnu/store/6xdd64b8343v9vd3nkhkkqg7mayyxvwp-gcc-5.3.0/arm-unknown-linux-gnueabihf/bin/ -B/gnu/store/6xdd64b8343v9vd3nkhkkqg7mayyxvwp-gcc-5.3.0/arm-unknown-linux-gnueabihf/lib/ -isystem /gnu/store/6xdd64b8343v9vd3nkhkkqg7mayyxvwp-gcc-5.3.0/arm-unknown-linux-gnueabihf/include -isystem /gnu/store/6xdd64b8343v9vd3nkhkkqg7mayyxvwp-gcc-5.3.0/arm-unknown-linux-gnueabihf/sys-include -DHAVE_CONFIG_H -I. -I../../../gcc-5.3.0/mpc/src -I.. -I/tmp/guix-build-gcc-5.3.0.drv-0/build/./gmp -I/tmp/guix-build-gcc-5.3.0.drv-0/gcc-5.3.0/mpfr/src -O2 -g0 -gtoggle -MT real.lo -MD -MP -MF .deps
 /real.Tpo -c ../../../gcc-5.3.0/mpc/src/real.c -o real.o
126915:libtool: compile:  /tmp/guix-build-gcc-5.3.0.drv-0/build/./prev-gcc/xgcc -B/tmp/guix-build-gcc-5.3.0.drv-0/build/./prev-gcc/ -B/gnu/store/6xdd64b8343v9vd3nkhkkqg7mayyxvwp-gcc-5.3.0/arm-unknown-linux-gnueabihf/bin/ -B/gnu/store/6xdd64b8343v9vd3nkhkkqg7mayyxvwp-gcc-5.3.0/arm-unknown-linux-gnueabihf/bin/ -B/gnu/store/6xdd64b8343v9vd3nkhkkqg7mayyxvwp-gcc-5.3.0/arm-unknown-linux-gnueabihf/lib/ -isystem /gnu/store/6xdd64b8343v9vd3nkhkkqg7mayyxvwp-gcc-5.3.0/arm-unknown-linux-gnueabihf/include -isystem /gnu/store/6xdd64b8343v9vd3nkhkkqg7mayyxvwp-gcc-5.3.0/arm-unknown-linux-gnueabihf/sys-include -DHAVE_CONFIG_H -I. -I../../../gcc-5.3.0/mpc/src -I.. -I/tmp/guix-build-gcc-5.3.0.drv-0/build/./gmp -I/tmp/guix-build-gcc-5.3.0.drv-0/gcc-5.3.0/mpfr/src -O2 -g0 -MT real.lo -MD -MP -MF .deps/real.Tpo
  -c ../../../gcc-5.3.0/mpc/src/real.c -o real.o

Maybe real.o is not the easiest example, since it also involves gmp and mpfr.

Andreas

Re: Freezing core-updates

[Ludovic Courtès]

Andreas Enge <andreas@enge.fr> skribis:

> On Tue, May 31, 2016 at 11:36:21PM +0200, Ludovic Courtès wrote:
>> Quick observation: one of the file has debugging symbols, the other not.
>> Apart from that, section sizes are very similar:
>
> That is understandable, the debugging symbols come from stage 2, the files
> without from stage 3.
>
>
> To check for an easy work-around, I tested to upgrade the standard gcc
> from 5.3 to 6.1. But this fails as follows:

Upgrading GCC is never this easy.  ;-)

> I find this:
> 105038:libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I../../../gcc-5.3.0/mpc/src -I.. -I/tmp/guix-build-gcc-5.3.0.drv-0/build/./gmp -I/tmp/guix-build-gcc-5.3.0.drv-0/gcc-5.3.0/mpfr/src -g -MT real.lo -MD -MP -MF .deps/real.Tpo -c ../../../gcc-5.3.0/mpc/src/real.c -o real.o
> 115976:libtool: compile:  /tmp/guix-build-gcc-5.3.0.drv-0/build/./prev-gcc/xgcc -B/tmp/guix-build-gcc-5.3.0.drv-0/build/./prev-gcc/ -B/gnu/store/6xdd64b8343v9vd3nkhkkqg7mayyxvwp-gcc-5.3.0/arm-unknown-linux-gnueabihf/bin/ -B/gnu/store/6xdd64b8343v9vd3nkhkkqg7mayyxvwp-gcc-5.3.0/arm-unknown-linux-gnueabihf/bin/ -B/gnu/store/6xdd64b8343v9vd3nkhkkqg7mayyxvwp-gcc-5.3.0/arm-unknown-linux-gnueabihf/lib/ -isystem /gnu/store/6xdd64b8343v9vd3nkhkkqg7mayyxvwp-gcc-5.3.0/arm-unknown-linux-gnueabihf/include -isystem /gnu/store/6xdd64b8343v9vd3nkhkkqg7mayyxvwp-gcc-5.3.0/arm-unknown-linux-gnueabihf/sys-include -DHAVE_CONFIG_H -I. -I../../../gcc-5.3.0/mpc/src -I.. -I/tmp/guix-build-gcc-5.3.0.drv-0/build/./gmp -I/tmp/guix-build-gcc-5.3.0.drv-0/gcc-5.3.0/mpfr/src -O2 -g0 -gtoggle -MT real.lo -MD -MP -MF .deps/real.Tpo -c ../../../gcc-5.3.0/mpc/src/real.c -o real.o
> 126915:libtool: compile:  /tmp/guix-build-gcc-5.3.0.drv-0/build/./prev-gcc/xgcc -B/tmp/guix-build-gcc-5.3.0.drv-0/build/./prev-gcc/ -B/gnu/store/6xdd64b8343v9vd3nkhkkqg7mayyxvwp-gcc-5.3.0/arm-unknown-linux-gnueabihf/bin/ -B/gnu/store/6xdd64b8343v9vd3nkhkkqg7mayyxvwp-gcc-5.3.0/arm-unknown-linux-gnueabihf/bin/ -B/gnu/store/6xdd64b8343v9vd3nkhkkqg7mayyxvwp-gcc-5.3.0/arm-unknown-linux-gnueabihf/lib/ -isystem /gnu/store/6xdd64b8343v9vd3nkhkkqg7mayyxvwp-gcc-5.3.0/arm-unknown-linux-gnueabihf/include -isystem /gnu/store/6xdd64b8343v9vd3nkhkkqg7mayyxvwp-gcc-5.3.0/arm-unknown-linux-gnueabihf/sys-include -DHAVE_CONFIG_H -I. -I../../../gcc-5.3.0/mpc/src -I.. -I/tmp/guix-build-gcc-5.3.0.drv-0/build/./gmp -I/tmp/guix-build-gcc-5.3.0.drv-0/gcc-5.3.0/mpfr/src -O2 -g0 -MT real.lo -MD -MP -MF .deps/real.Tpo -c ../../../gcc-5.3.0/mpc/src/real.c -o real.o

This is the wrong one; you should look at gcc/real.c instead.

Thanks for helping out!

Ludo’.

Re: Freezing core-updates

[Andreas Enge]

On Thu, Jun 02, 2016 at 10:09:36AM +0200, Ludovic Courtès wrote:
> > 126915:libtool: compile:  /tmp/guix-build-gcc-5.3.0.drv-0/build/./prev-gcc/xgcc -B/tmp/guix-build-gcc-5.3.0.drv-0/build/./prev-gcc/ -B/gnu/store/6xdd64b8343v9vd3nkhkkqg7mayyxvwp-gcc-5.3.0/arm-unknown-linux-gnueabihf/bin/ -B/gnu/store/6xdd64b8343v9vd3nkhkkqg7mayyxvwp-gcc-5.3.0/arm-unknown-linux-gnueabihf/bin/ -B/gnu/store/6xdd64b8343v9vd3nkhkkqg7mayyxvwp-gcc-5.3.0/arm-unknown-linux-gnueabihf/lib/ -isystem /gnu/store/6xdd64b8343v9vd3nkhkkqg7mayyxvwp-gcc-5.3.0/arm-unknown-linux-gnueabihf/include -isystem /gnu/store/6xdd64b8343v9vd3nkhkkqg7mayyxvwp-gcc-5.3.0/arm-unknown-linux-gnueabihf/sys-include -DHAVE_CONFIG_H -I. -I../../../gcc-5.3.0/mpc/src -I.. -I/tmp/guix-build-gcc-5.3.0.drv-0/build/./gmp -I/tmp/guix-build-gcc-5.3.0.drv-0/gcc-5.3.0/mpfr/src -O2 -g0 -MT real.lo -MD -MP -MF .deps/real
 .Tpo -c ../../../gcc-5.3.0/mpc/src/real.c -o real.o
> This is the wrong one; you should look at gcc/real.c instead.

Ah indeed, real.c is just not such a distinctive file name... Thanks for
looking into it instead of me :-)

Andreas

GCC bootstrap failure on ARM

[Ludovic Courtès]

Andreas Enge <andreas@enge.fr> skribis:

> On Sat, May 28, 2016 at 05:25:35PM +0200, Ludovic Courtès wrote:
>> Could you save the offending .o files that are listed and upload them
>> somewhere, or run diffoscope on them?
>
> Of course the first time I forgot to add the "-K" parameter. So I redid the
> build and saved the build tree. Here is the error message:
> Comparing stages 2 and 3
> warning: gcc/cc1plus-checksum.o differs
> warning: gcc/cc1-checksum.o differs
> Bootstrap comparison failure!

I tried building it on an ARM machine that I borrowed (a rpi3), but with
a bit less than 1G of RAM and 100MiB of swap, it eventually runs out of
memory:

--8<---------------cut here---------------start------------->8---
g++ -c  -DIN_GCC_FRONTEND -DIN_GCC_FRONTEND -g -DIN_GCC    -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-format -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common  -DHAVE_CONFIG_H -I. -Ic-family -I../../gcc-5.3.0/gcc -I../../gcc-5.3.0/gcc/c-family -I../../gcc-5.3.0/gcc/../include -I../../gcc-5.3.0/gcc/../libcpp/include -I/tmp/guix-build-gcc-5.3.0.drv-0/build/./gmp -I/tmp/guix-build-gcc-5.3.0.drv-0/gcc-5.3.0/gmp -I/tmp/guix-build-gcc-5.3.0.drv-0/build/./mpfr/src -I/tmp/guix-build-gcc-5.3.0.drv-0/gcc-5.3.0/mpfr/src -I/tmp/guix-build-gcc-5.3.0.drv-0/gcc-5.3.0/mpc/src  -I../../gcc-5.3.0/gcc/../libdecnumber -I../../gcc-5.3.0/gcc/../libdecnumber/dpd -I../libdecnumber -I../../gcc-5.3.0/gcc/../libbacktrace   -o c-family/c-cppbuiltin.o -MT c-family/c-cppbuiltin.o -MMD -MP -MF c-family/.deps/c-cppbuiltin.TPo ../../gcc-5.3.0/gcc/c-family/c-cppbuiltin.c
/gnu/store/fi2yn5m40bls0kbi8km7an6l8dmywqhs-bash-static-4.3.42/bin/bash: line 1: 29443 Killed                  build/genautomata ../../gcc-5.3.0/gcc/common.md ../../gcc-5.3.0/gcc/config/arm/arm.md insn-conditions.md > tmp-automata.c
Makefile:2137: recipe for target 's-automata' failed
make[3]: *** [s-automata] Error 137
--8<---------------cut here---------------end--------------->8---

Details:

--8<---------------cut here---------------start------------->8---
$ dmesg |tail
[15555.066542] [23977]   999 23977     1997     1659       7       0        0             0 make
[15555.066562] [24788]   999 24788    43191    42723      87       0        0             0 genattrtab
[15555.066581] [24796]   999 24796      272        3       3       0        0             0 bash
[15555.066601] [24797]   999 24797   116661   116191     230       0        0             0 genautomata
[15555.066621] [24895]   999 24895      599       15       3       0        0             0 arm-guix-linux-
[15555.066641] [24896]   999 24896    23700    19432      48       0        0             0 cc1plus
[15555.066660] [24899]   999 24899      599       15       3       0        0             0 arm-guix-linux-
[15555.066680] [24900]   999 24900     5935     1993      13       0        0             0 cc1plus
[15555.066695] Out of memory: Kill process 24797 (genautomata) score 443 or sacrifice child
[15555.066715] Killed process 24797 (genautomata) total-vm:466644kB, anon-rss:464724kB, file-rss:40kB
--8<---------------cut here---------------end--------------->8---

Since the full log vanished from hydra.gnu.org (now we have a truncated
log), could you post the full log somewhere?

Alternately, if you want, you cuold give me access to your Novena.  :-)

Thanks,
Ludo’.

Re: GCC bootstrap failure on ARM

[Andreas Enge]

On Wed, Jun 01, 2016 at 02:23:15PM +0200, Ludovic Courtès wrote:
> Since the full log vanished from hydra.gnu.org (now we have a truncated
> log), could you post the full log somewhere?
> 
> Alternately, if you want, you cuold give me access to your Novena.  :-)

That sounds like the easiest solution; more details in a private message.

Andreas

Re: GCC bootstrap failure on ARM

[Ludovic Courtès]

Hello!

For the record, at this point I’m mostly relying on the GCC developers
to help with this failure.  I’ve reported the issue at:

  https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71399

Ludo’.

Re: GCC bootstrap failure on ARM

[Ludovic Courtès]

Hi!

ludo@gnu.org (Ludovic Courtès) skribis:

> For the record, at this point I’m mostly relying on the GCC developers
> to help with this failure.  I’ve reported the issue at:
>
>   https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71399

Because this has already taken too much time, I’ve reverted the GCC 5
upgrade in commit 9dee9e8ffe4650949bd3ad2edf559cf4a33e9e6e.

I hope we can make progress on this soon.  In the meantime, I think we
should do a bit of “ungrafting” in core-updates and get it built.

Thoughts?

Ludo’.

Re: GCC bootstrap failure on ARM

[Leo Famulari]

On Tue, Jun 07, 2016 at 11:58:32AM +0200, Ludovic Courtès wrote:
> Hi!
> 
> ludo@gnu.org (Ludovic Courtès) skribis:
> 
> > For the record, at this point I’m mostly relying on the GCC developers
> > to help with this failure.  I’ve reported the issue at:
> >
> >   https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71399
> 
> Because this has already taken too much time, I’ve reverted the GCC 5
> upgrade in commit 9dee9e8ffe4650949bd3ad2edf559cf4a33e9e6e.
> 
> I hope we can make progress on this soon.  In the meantime, I think we
> should do a bit of “ungrafting” in core-updates and get it built.

I tried doing something like this for expat and libxslt, but the
situation was rather complicated because the packages had been changed
independently on master and core-updates. I'll make another attempt
today and report back.

Re: GCC bootstrap failure on ARM

[Leo Famulari]

On Tue, Jun 07, 2016 at 12:04:09PM -0400, Leo Famulari wrote:
> On Tue, Jun 07, 2016 at 11:58:32AM +0200, Ludovic Courtès wrote:
> > Hi!
> > 
> > ludo@gnu.org (Ludovic Courtès) skribis:
> > 
> > > For the record, at this point I’m mostly relying on the GCC developers
> > > to help with this failure.  I’ve reported the issue at:
> > >
> > >   https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71399
> > 
> > Because this has already taken too much time, I’ve reverted the GCC 5
> > upgrade in commit 9dee9e8ffe4650949bd3ad2edf559cf4a33e9e6e.
> > 
> > I hope we can make progress on this soon.  In the meantime, I think we
> > should do a bit of “ungrafting” in core-updates and get it built.
> 
> I tried doing something like this for expat and libxslt, but the
> situation was rather complicated because the packages had been changed
> independently on master and core-updates. I'll make another attempt
> today and report back.

I sent my proposed changes for review in a separate email
(git-send-email is convenient).

Re: GCC bootstrap failure on ARM

[Andreas Enge]

Hello,

On Tue, Jun 07, 2016 at 11:58:32AM +0200, Ludovic Courtès wrote:
> I hope we can make progress on this soon.  In the meantime, I think we
> should do a bit of “ungrafting” in core-updates and get it built.

the core subset built well (on mips, a few packages are still missing),
so I started a full evaluation on hydra. If anything goes wrong, please do not
hesitate to interrupt the builds.

Andreas

Re: GCC bootstrap failure on ARM

[Efraim Flashner]

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

On Fri, Jun 10, 2016 at 11:13:43AM +0200, Andreas Enge wrote:
> Hello,
> 
> On Tue, Jun 07, 2016 at 11:58:32AM +0200, Ludovic Courtès wrote:
> > I hope we can make progress on this soon.  In the meantime, I think we
> > should do a bit of “ungrafting” in core-updates and get it built.
> 
> the core subset built well (on mips, a few packages are still missing),
> so I started a full evaluation on hydra. If anything goes wrong, please do not
> hesitate to interrupt the builds.
> 
> Andreas
> 

time to run `guix gc' and get ready to fix some of the build errors that
I'm sure I helped cause! :)

-- 
Efraim Flashner   <efraim@flashner.co.il>   אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: GCC bootstrap failure on ARM

[Efraim Flashner]

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

On Fri, Jun 10, 2016 at 03:16:18PM +0300, Efraim Flashner wrote:
> On Fri, Jun 10, 2016 at 11:13:43AM +0200, Andreas Enge wrote:
> > Hello,
> > 
> > On Tue, Jun 07, 2016 at 11:58:32AM +0200, Ludovic Courtès wrote:
> > > I hope we can make progress on this soon.  In the meantime, I think we
> > > should do a bit of “ungrafting” in core-updates and get it built.
> > 
> > the core subset built well (on mips, a few packages are still missing),
> > so I started a full evaluation on hydra. If anything goes wrong, please do not
> > hesitate to interrupt the builds.
> > 
> > Andreas
> > 
> 
> time to run `guix gc' and get ready to fix some of the build errors that
> I'm sure I helped cause! :)
> 

I realized after I sent the e-mail it wasn't clear that I mean *I* need
to get ready for fixing, not that everyone should get ready and fix what
I did (mumble mumble something about sentence parsing and missing
subjects)

-- 
Efraim Flashner   <efraim@flashner.co.il>   אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: GCC bootstrap failure on ARM

[Mark H Weaver]

Picking up an old thread...

ludo@gnu.org (Ludovic Courtès) writes:

> For the record, at this point I’m mostly relying on the GCC developers
> to help with this failure.  I’ve reported the issue at:
>
>   https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71399

Interestingly, a similar bootstrapping failure is now happening with
GCC-4.9.4 on the current 'core-updates' branch:

  https://hydra.gnu.org/build/1444118/nixlog/2/tail-reload

This suggests the possibility of performing a 'git bisect' between 4.9.3
and 4.9.4 and finding out which commit introduced this problem.

      Mark

Re: GCC bootstrap failure on ARM

[David Craven]

I can help fixing package regressions if someone gets the ball
rolling. Is there a reason to upgrade to gcc 5 or does it make sense
to jump to gcc 6 directly? If I understand correctly most of the work
required for an update to gcc 5 has already been done?

Re: GCC bootstrap failure on ARM

[David Craven]

Why are we using different package versions for the arm bootstrap
binaries than for other platforms?

Re: GCC bootstrap failure on ARM

[Andreas Enge]

On Sun, Aug 21, 2016 at 02:17:10PM +0200, David Craven wrote:
> Why are we using different package versions for the arm bootstrap
> binaries than for other platforms?

Simply because they have been created later, and there was no reason
to change the existing ones.

Andreas

Re: GCC bootstrap failure on ARM

[Mark H Weaver]

David Craven <david@craven.ch> writes:

> I can help fixing package regressions if someone gets the ball
> rolling. Is there a reason to upgrade to gcc 5 or does it make sense
> to jump to gcc 6 directly? If I understand correctly most of the work
> required for an update to gcc 5 has already been done?

Until the bootstrapping problem on ARM is fixed, we can't do any of
this.  At the moment, that's blocking us from even updating to 4.9.4,
nevermind 5 or 6.  If you want to help us upgrade our default GCC,
investigating that problem would be the best way.

       Mark

Re: GCC bootstrap failure on ARM

[David Craven]

> Until the bootstrapping problem on ARM is fixed, we can't do any of
> this.  At the moment, that's blocking us from even updating to 4.9.4,
> nevermind 5 or 6.  If you want to help us upgrade our default GCC,
> investigating that problem would be the best way.

I have some unfinished stuff that I want to check of my todo list before
starting something like this... But I guess everyone is in the same boat
in this regard =)

Re: GCC bootstrap failure on ARM

[Ludovic Courtès]

Mark H Weaver <mhw@netris.org> skribis:

> David Craven <david@craven.ch> writes:
>
>> I can help fixing package regressions if someone gets the ball
>> rolling. Is there a reason to upgrade to gcc 5 or does it make sense
>> to jump to gcc 6 directly? If I understand correctly most of the work
>> required for an update to gcc 5 has already been done?
>
> Until the bootstrapping problem on ARM is fixed, we can't do any of
> this.  At the moment, that's blocking us from even updating to 4.9.4,
> nevermind 5 or 6.  If you want to help us upgrade our default GCC,
> investigating that problem would be the best way.

It might be that fixing bootstrap with GCC 5 (or 6) or ARM wouldn’t be
much harder than with 4.9.

For the record, this is how far I got with GCC 5:

  https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71399

It’s intimidating, but if several of us give it a try, we may get better
ideas.

Cheers,
Ludo’.

Re: GCC bootstrap failure on ARM

[Ludovic Courtès]

ludo@gnu.org (Ludovic Courtès) skribis:

> Mark H Weaver <mhw@netris.org> skribis:
>
>> David Craven <david@craven.ch> writes:
>>
>>> I can help fixing package regressions if someone gets the ball
>>> rolling. Is there a reason to upgrade to gcc 5 or does it make sense
>>> to jump to gcc 6 directly? If I understand correctly most of the work
>>> required for an update to gcc 5 has already been done?
>>
>> Until the bootstrapping problem on ARM is fixed, we can't do any of
>> this.  At the moment, that's blocking us from even updating to 4.9.4,
>> nevermind 5 or 6.  If you want to help us upgrade our default GCC,
>> investigating that problem would be the best way.
>
> It might be that fixing bootstrap with GCC 5 (or 6) or ARM wouldn’t be
> much harder than with 4.9.
>
> For the record, this is how far I got with GCC 5:
>
>   https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71399

I’ve made some progress on this, as reported on bugzilla.  I’m now
trying to bisect the issue; however, since the bootstrapping failure of
gcc-final is due to a problem that manifests in gcc-boot0, that’s a lot
of rebuild, and the machine I’m using (redhill) is slow.

Anyway, we’ll have a patch reverting a few 4.9.3-to-4.9.4 commits, and
that’ll allow us to proceed.  I’d like to reduce that patch as much as
possible, but I’d like to stop researching by the end of next week so we
can then freeze core-updates.

Ludo’.

Re: GCC bootstrap failure on ARM

[David Craven]

> I’ve made some progress on this, as reported on bugzilla.  I’m now
> trying to bisect the issue; however, since the bootstrapping failure of
> gcc-final is due to a problem that manifests in gcc-boot0, that’s a lot
> of rebuild, and the machine I’m using (redhill) is slow.
>
> Anyway, we’ll have a patch reverting a few 4.9.3-to-4.9.4 commits, and
> that’ll allow us to proceed.  I’d like to reduce that patch as much as
> possible, but I’d like to stop researching by the end of next week so we
> can then freeze core-updates.

Awesome! Thanks for taking on this time consuming task...

Re: GCC bootstrap failure on ARM

[Ludovic Courtès]

ludo@gnu.org (Ludovic Courtès) skribis:

> ludo@gnu.org (Ludovic Courtès) skribis:

[...]

>> For the record, this is how far I got with GCC 5:
>>
>>   https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71399
>
> I’ve made some progress on this, as reported on bugzilla.  I’m now
> trying to bisect the issue; however, since the bootstrapping failure of
> gcc-final is due to a problem that manifests in gcc-boot0, that’s a lot
> of rebuild, and the machine I’m using (redhill) is slow.
>
> Anyway, we’ll have a patch reverting a few 4.9.3-to-4.9.4 commits, and
> that’ll allow us to proceed.  I’d like to reduce that patch as much as
> possible, but I’d like to stop researching by the end of next week so we
> can then freeze core-updates.

‘core-updates’ is now building with a tiny patch on gcc-4.9 (in fact
it’s enough to apply it to gcc-cross-boot0, which is interesting):

  https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71399#c12

Ludo’.

Re: GCC bootstrap failure on ARM

[David Craven]

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

> ‘core-updates’ is now building with a tiny patch on gcc-4.9 (in fact
> it’s enough to apply it to gcc-cross-boot0, which is interesting):

Does this also fix the bootstrap failure with gcc 5? Or is that too late
for this core-updates cycle?

[-- Attachment #2: Type: text/html, Size: 295 bytes --]

Re: GCC bootstrap failure on ARM

[Ludovic Courtès]

David Craven <david@craven.ch> skribis:

>> ‘core-updates’ is now building with a tiny patch on gcc-4.9 (in fact
>> it’s enough to apply it to gcc-cross-boot0, which is interesting):
>
> Does this also fix the bootstrap failure with gcc 5? Or is that too late
> for this core-updates cycle?

I think we should rather wait for the next cycle, because it’s likely to
delay us further.

Ludo’.

Binutils build failure on MIPS

[Ludovic Courtès]

ludo@gnu.org (Ludovic Courtès) skribis:

> ‘core-updates’ is now building with a tiny patch on gcc-4.9 (in fact
> it’s enough to apply it to gcc-cross-boot0, which is interesting):
>
>   https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71399#c12

And now for MIPS!  I was so joyful that I almost forgot that
binutils-cross-boot0-2.27 fails to build on MIPS:

  https://hydra.gnu.org/build/1470440/nixlog/3/raw

I cannot find any error message in the build log, so I don’t know what’s
going on.

Could someone take a look?

Thanks,
Ludo’.

Re: Binutils build failure on MIPS

[Vincent Legoll]

On Tue, Sep 13, 2016 at 10:26 AM, Ludovic Courtès <ludo@gnu.org> wrote:
> ludo@gnu.org (Ludovic Courtès) skribis:
>
>> ‘core-updates’ is now building with a tiny patch on gcc-4.9 (in fact
>> it’s enough to apply it to gcc-cross-boot0, which is interesting):
>>
>>   https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71399#c12
>
> And now for MIPS!  I was so joyful that I almost forgot that
> binutils-cross-boot0-2.27 fails to build on MIPS:
>
>   https://hydra.gnu.org/build/1470440/nixlog/3/raw
>
> I cannot find any error message in the build log, so I don’t know what’s
> going on.
>
> Could someone take a look?

I found this:

/tmp/nix-build-binutils-cross-boot0-2.27.drv-0/binutils-2.27/ld/configure:
unhandled emulation
[...]
make[1]: *** [Makefile:7125: configure-ld] Error 1
make[1]: *** Waiting for unfinished jobs....

Something similar was discussed in comp.gnu.binutils, it was also about mips...

http://webcache.googleusercontent.com/search?q=cache:waWLFBpEIPQJ:permalink.gmane.org/gmane.comp.gnu.binutils/69283+&cd=1&hl=en&ct=clnk&gl=us&lr=lang_de%7Clang_en%7Clang_fr

But GMane has still not restored all ML archives.

Trying to find more infos...

-- 
Vincent Legoll

Re: Binutils build failure on MIPS

[Vincent Legoll]

> Trying to find more infos...

Thread from April 2015:

https://sourceware.org/ml/binutils/2015-04/msg00118.html

But as 2.27 is recent this should already be checked-in...

How does one reproduce the failure ?

-- 
Vincent Legoll

Re: Binutils build failure on MIPS

[Ludovic Courtès]

Vincent Legoll <vincent.legoll@gmail.com> skribis:

>> Trying to find more infos...
>
> Thread from April 2015:
>
> https://sourceware.org/ml/binutils/2015-04/msg00118.html
>
> But as 2.27 is recent this should already be checked-in...

The fix at <https://sourceware.org/ml/binutils/2015-04/msg00137.html> is
definitely in binutils-2.27.tar.bz2, yet we get an error that suggests
$EMULATION_NAME is empty.  Dunno what’s going on.

> How does one reproduce the failure ?

You need a mips64el machine to run:

  ./pre-inst-env guix build -e '(@@ (gnu packages commencement) binutils-boot0)'

Ludo’.

Re: Binutils build failure on MIPS

[Vincent Legoll]

> The fix at <https://sourceware.org/ml/binutils/2015-04/msg00137.html> is
> definitely in binutils-2.27.tar.bz2, yet we get an error that suggests
> $EMULATION_NAME is empty.  Dunno what’s going on.
>
>> How does one reproduce the failure ?
>
> You need a mips64el machine to run:

I don't have that...

Could it be that "mips64el-linux" is not matched by the switch/case from
binutils/ld/configure.tgt which only contains:

$ grep '^mips' configure.tgt
mips*-sgi-irix5*)    targ_emul=elf32bsmip ;;
mips*-sgi-irix6*)    targ_emul=elf32bmipn32
mips*el-*-netbsd*)    targ_emul=elf32ltsmip
mips*-*-netbsd*)    targ_emul=elf32btsmip
mips*vr4300el-*-elf*)    targ_emul=elf32l4300 ;;
mips*vr4300-*-elf*)    targ_emul=elf32b4300 ;;
mips*vr4100el-*-elf*)    targ_emul=elf32l4300 ;;
mips*vr4100-*-elf*)    targ_emul=elf32b4300 ;;
mips*vr5000el-*-elf*)    targ_emul=elf32l4300 ;;
mips*vr5000-*-elf*)    targ_emul=elf32b4300 ;;
mips*el-sde-elf* | mips*el-mti-elf* | mips*el-img-elf*)
mips*-sde-elf* | mips*-mti-elf* | mips*-img-elf*)
mips64*el-ps2-elf*)    targ_emul=elf32lr5900n32
mips*el-ps2-elf*)    targ_emul=elf32lr5900
mips*el-*-elf*)        targ_emul=elf32elmip ;;
mips*-*-elf*)        targ_emul=elf32ebmip ;;
mips*-*-rtems*)        targ_emul=elf32ebmip ;;
mips*el-*-vxworks*)    targ_emul=elf32elmipvxworks
mips*-*-vxworks*)    targ_emul=elf32ebmipvxworks
mips*-*-windiss)    targ_emul=elf32mipswindiss ;;
mips64*el-*-linux-*)    targ_emul=elf32ltsmipn32
mips64*-*-linux-*)    targ_emul=elf32btsmipn32
mips*el-*-linux-*)    targ_emul=elf32ltsmip
mips*-*-linux-*)    targ_emul=elf32btsmip
mips64*el-*-freebsd* | mips64*el-*-kfreebsd*-gnu)
mips64*-*-freebsd* | mips64*-*-kfreebsd*-gnu)
mips*el-*-freebsd* | mips*el-*-kfreebsd*-gnu)
mips*-*-freebsd* | mips*-*-kfreebsd*-gnu)
mips*-*-sysv4*)         targ_emul=elf32btsmip

Could that explain the failure ?

-- 
Vincent Legoll

Re: Binutils build failure on MIPS

[David Craven]

> Could that explain the failure ?

It's matched here:
> mips64*el-*-linux-*)    targ_emul=elf32ltsmipn32

I believe that the -*- part means any cpu model.

Since it's a build failure you might get away with cross-compiling.
Try passing --target mips64el-linux-gnu (or whatever the
mipsel-gcc-toolchain uses)

Re: Binutils build failure on MIPS

[Vincent Legoll]

Hello,

On Tue, Sep 13, 2016 at 4:05 PM, David Craven <david@craven.ch> wrote:
>> Could that explain the failure ?
>
> It's matched here:
>> mips64*el-*-linux-*)    targ_emul=elf32ltsmipn32

I'm not sure I understand what your saying:

$ python
>>> import fnmatch
>>> fnmatch.fnmatch('mips64el-linux', 'mips64*el-*-linux-*')
False

-- 
Vincent Legoll

Re: Binutils build failure on MIPS

[David Craven]

I highly doubt that binutils uses python, and I'm not sure why you
think that this is a filename - so why would unix filename matching
apply in this instance?

There must be a match somewhere... Either mips64*el-*-linux means any
cpu model or you've missed a part of the matching code. I remember GCC
having that spread out over three parts of a file.

Re: Binutils build failure on MIPS

[Vincent Legoll]

On Tue, Sep 13, 2016 at 4:27 PM, David Craven <david@craven.ch> wrote:
> I highly doubt that binutils uses python, and I'm not sure why you
> think that this is a filename - so why would unix filename matching
> apply in this instance?

I know it's not exactly the same, but python fnmatch is probably doing
(almost) the same as bash's, and bash switch/case may also use
fnmatching, that was for illustration purpose.

And now after reading a bit of man bash:

A case command first expands word, and tries to match it against each
pattern in turn, using the same matching rules as for pathname expansion

So "-*-" will match "--", "-gnu-", etc... but neither "-" nor ""...

> There must be a match somewhere...

Maybe, I report my findings as I go, and I've still not looked everywhere...
;-)

But that looked sufficiently suspicious that I wanted to shared my findings...

> Either mips64*el-*-linux means any cpu model or you've missed a part
> of the matching code. I remember GCC having that spread out over
> three parts of a file.

I'll look harder

-- 
Vincent Legoll

Re: Binutils build failure on MIPS

[Ludovic Courtès]

Vincent Legoll <vincent.legoll@gmail.com> skribis:

> Hello,
>
> On Tue, Sep 13, 2016 at 4:05 PM, David Craven <david@craven.ch> wrote:
>>> Could that explain the failure ?
>>
>> It's matched here:
>>> mips64*el-*-linux-*)    targ_emul=elf32ltsmipn32
>
> I'm not sure I understand what your saying:
>
> $ python
>>>> import fnmatch
>>>> fnmatch.fnmatch('mips64el-linux', 'mips64*el-*-linux-*')

Note that here we pass the triplet “mips64el-guix-linux-gnu” (this can
be seen at the beginning of the configure phase in the build log.)

Ludo’.

Re: Binutils build failure on MIPS

[Andreas Enge]

Hello,
Hello,

On Tue, Sep 13, 2016 at 02:45:40PM +0200, Ludovic Courtès wrote:
> You need a mips64el machine to run:
>   ./pre-inst-env guix build -e '(@@ (gnu packages commencement) binutils-boot0)'

I just did this (together with the paramater "-K"!), but the problem is
that I have no idea what is happening inside...

The configure phase actually passes, the problem appears inside the build
phase, which itself launches a number of configure runs in subdirectories.
The last lines of the log are:
checking size of void *... 4
/tmp/guix-build-binutils-cross-boot0-2.27.drv-0/binutils-2.27/ld/configure: unhandled emulation
make[1]: *** [Makefile:7125: configure-ld] Error 1
make[1]: Leaving directory '/tmp/guix-build-binutils-cross-boot0-2.27.drv-0/binutils-2.27'
make: *** [Makefile:852: all] Error 2
phase `build' failed after 1434.0 seconds
note: keeping build directory `/tmp/guix-build-binutils-cross-boot0-2.27.drv-1'
builder for `/gnu/store/yw6kb2vqqws3gnrmvlp44h60rlpw4ldr-binutils-cross-boot0-2.27.drv' failed with exit code 1
@ build-failed /gnu/store/yw6kb2vqqws3gnrmvlp44h60rlpw4ldr-binutils-cross-boot0-2.27.drv - 1 builder for `/gnu/store/yw6kb2vqqws3gnrmvlp44h60rlpw4ldr-binutils-cross-boot0-2.27.drv' failed with exit code 1
guix build: error: build failed: build of `/gnu/store/yw6kb2vqqws3gnrmvlp44h60rlpw4ldr-binutils-cross-boot0-2.27.drv' failed

I launched a ./configure by hand inside the ld subdirectory, after sourcing
the environment variables; it succeeds with
checking size of void *... 4
configure: creating ./config.status
config.status: creating Makefile
config.status: creating po/Makefile.in
config.status: creating config.h
config.status: config.h is unchanged
config.status: executing depfiles commands
config.status: executing libtool commands
config.status: executing default-1 commands
config.status: creating po/POTFILES
config.status: creating po/Makefile

So even during the build, configure runs until the last test.
However, it does not write ./config.status etc.

The error message above contains
make[1]: *** [Makefile:7125: configure-ld] Error 1

Lines 7125 and following of the Makefile (one level up from the ld
subdirectory) are
configure-ld:
        @r=`${PWD_COMMAND}`; export r; \
        s=`cd $(srcdir); ${PWD_COMMAND}`; export s; \
        test ! -f $(HOST_SUBDIR)/ld/Makefile || exit 0; \
        $(SHELL) $(srcdir)/mkinstalldirs $(HOST_SUBDIR)/ld; \
        $(HOST_EXPORTS)  \
        echo Configuring in $(HOST_SUBDIR)/ld; \
        cd "$(HOST_SUBDIR)/ld" || exit 1; \
        case $(srcdir) in \
          /* | [A-Za-z]:[\\/]*) topdir=$(srcdir) ;; \
          *) topdir=`echo $(HOST_SUBDIR)/ld/ | \
                sed -e 's,\./,,g' -e 's,[^/]*/,../,g' `$(srcdir) ;; \
        esac; \
        module_srcdir=ld; \
        $(SHELL) \
          $$s/$$module_srcdir/configure \
          --srcdir=$${topdir}/$$module_srcdir \
          $(HOST_CONFIGARGS) --build=${build_alias} --host=${host_alias} \
          --target=${target_alias}  \
          || exit 1

So apparently the "exit 1" is triggered.
The beginning of the configure log looks like this:
Configuring in ./ld
configure: creating cache ./config.cache
checking build system type... mips64el-unknown-linux-gnu
checking host system type... mips64el-unknown-linux-gnu
checking target system type... mips64el-guix-linux-gnu
So it looks as if build_alias, host_alias and target_alias are set
correctly.

Do you have any ideas of what to check?

Andreas

Re: Binutils build failure on MIPS

[Ludovic Courtès]

Hi!

Andreas Enge <andreas@enge.fr> skribis:

> On Tue, Sep 13, 2016 at 02:45:40PM +0200, Ludovic Courtès wrote:
>> You need a mips64el machine to run:
>>   ./pre-inst-env guix build -e '(@@ (gnu packages commencement) binutils-boot0)'
>
> I just did this (together with the paramater "-K"!), but the problem is
> that I have no idea what is happening inside...
>
> The configure phase actually passes, the problem appears inside the build
> phase, which itself launches a number of configure runs in subdirectories.
> The last lines of the log are:
> checking size of void *... 4
> /tmp/guix-build-binutils-cross-boot0-2.27.drv-0/binutils-2.27/ld/configure: unhandled emulation
> make[1]: *** [Makefile:7125: configure-ld] Error 1
> make[1]: Leaving directory '/tmp/guix-build-binutils-cross-boot0-2.27.drv-0/binutils-2.27'
> make: *** [Makefile:852: all] Error 2
> phase `build' failed after 1434.0 seconds
> note: keeping build directory `/tmp/guix-build-binutils-cross-boot0-2.27.drv-1'
> builder for `/gnu/store/yw6kb2vqqws3gnrmvlp44h60rlpw4ldr-binutils-cross-boot0-2.27.drv' failed with exit code 1
> @ build-failed /gnu/store/yw6kb2vqqws3gnrmvlp44h60rlpw4ldr-binutils-cross-boot0-2.27.drv - 1 builder for `/gnu/store/yw6kb2vqqws3gnrmvlp44h60rlpw4ldr-binutils-cross-boot0-2.27.drv' failed with exit code 1
> guix build: error: build failed: build of `/gnu/store/yw6kb2vqqws3gnrmvlp44h60rlpw4ldr-binutils-cross-boot0-2.27.drv' failed
>
> I launched a ./configure by hand inside the ld subdirectory, after sourcing
> the environment variables; it succeeds with
> checking size of void *... 4
> configure: creating ./config.status
> config.status: creating Makefile
> config.status: creating po/Makefile.in
> config.status: creating config.h
> config.status: config.h is unchanged
> config.status: executing depfiles commands
> config.status: executing libtool commands
> config.status: executing default-1 commands
> config.status: creating po/POTFILES
> config.status: creating po/Makefile
>
> So even during the build, configure runs until the last test.
> However, it does not write ./config.status etc.
>
> The error message above contains
> make[1]: *** [Makefile:7125: configure-ld] Error 1
>
> Lines 7125 and following of the Makefile (one level up from the ld
> subdirectory) are
> configure-ld:
>         @r=`${PWD_COMMAND}`; export r; \
>         s=`cd $(srcdir); ${PWD_COMMAND}`; export s; \
>         test ! -f $(HOST_SUBDIR)/ld/Makefile || exit 0; \
>         $(SHELL) $(srcdir)/mkinstalldirs $(HOST_SUBDIR)/ld; \
>         $(HOST_EXPORTS)  \
>         echo Configuring in $(HOST_SUBDIR)/ld; \
>         cd "$(HOST_SUBDIR)/ld" || exit 1; \
>         case $(srcdir) in \
>           /* | [A-Za-z]:[\\/]*) topdir=$(srcdir) ;; \
>           *) topdir=`echo $(HOST_SUBDIR)/ld/ | \
>                 sed -e 's,\./,,g' -e 's,[^/]*/,../,g' `$(srcdir) ;; \
>         esac; \
>         module_srcdir=ld; \
>         $(SHELL) \
>           $$s/$$module_srcdir/configure \
>           --srcdir=$${topdir}/$$module_srcdir \
>           $(HOST_CONFIGARGS) --build=${build_alias} --host=${host_alias} \
>           --target=${target_alias}  \
>           || exit 1
>
> So apparently the "exit 1" is triggered.
> The beginning of the configure log looks like this:
> Configuring in ./ld
> configure: creating cache ./config.cache
> checking build system type... mips64el-unknown-linux-gnu
> checking host system type... mips64el-unknown-linux-gnu
> checking target system type... mips64el-guix-linux-gnu
> So it looks as if build_alias, host_alias and target_alias are set
> correctly.
>
> Do you have any ideas of what to check?

Could you check the values of _alias in the top-level Makefile?

Alternately, could you edit ld/emulparams/elf32bmipn32-defs.sh and add
‘set’ just before the “unhandled emulation” line in order to see the
value of the variables?

I tried this on my x86_64 machine:

  ./configure -C --prefix=$HOME/soft --build=mips64el-unknown-linux-gnu --target=mips64el-guix-linux-gnu

to mimic the configure flags shown at
<https://hydra.gnu.org/build/1470440/nixlog/4/raw>.  Unfortunately it
doesn’t exhibit the problem.

Thanks for looking into it!

Ludo’.

Re: Binutils build failure on MIPS

[Ludovic Courtès]

Hello!

Vincent Legoll <vincent.legoll@gmail.com> skribis:

> On Tue, Sep 13, 2016 at 10:26 AM, Ludovic Courtès <ludo@gnu.org> wrote:
>> ludo@gnu.org (Ludovic Courtès) skribis:

[...]

>> And now for MIPS!  I was so joyful that I almost forgot that
>> binutils-cross-boot0-2.27 fails to build on MIPS:
>>
>>   https://hydra.gnu.org/build/1470440/nixlog/3/raw
>>
>> I cannot find any error message in the build log, so I don’t know what’s
>> going on.
>>
>> Could someone take a look?
>
> I found this:
>
> /tmp/nix-build-binutils-cross-boot0-2.27.drv-0/binutils-2.27/ld/configure:
> unhandled emulation
> [...]
> make[1]: *** [Makefile:7125: configure-ld] Error 1
> make[1]: *** Waiting for unfinished jobs....
>
> Something similar was discussed in comp.gnu.binutils, it was also about mips...
>
> http://webcache.googleusercontent.com/search?q=cache:waWLFBpEIPQJ:permalink.gmane.org/gmane.comp.gnu.binutils/69283+&cd=1&hl=en&ct=clnk&gl=us&lr=lang_de%7Clang_en%7Clang_fr

This is fixed in 789f09a073a7239aee2e551d52b5b5ea9f41bb90!  \o/

It was a silly Bash 4.2 bug described in:

  http://ftp.gnu.org/gnu/bash/bash-4.2-patches/bash42-007

Ludo’.