GNU bug report logs - #21720
Building gcc fails at target s-attrtab

Previous Next

Package: guix;

Reported by: Aljosha Papsch <lists <at> rpapsch.de>

Date: Tue, 20 Oct 2015 17:33:01 UTC

Severity: normal

Tags: notabug

Done: ludo <at> gnu.org (Ludovic Courtès)

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Aljosha Papsch <lists <at> rpapsch.de>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: 21720 <at> debbugs.gnu.org
Subject: bug#21720: Building gcc fails at target s-attrtab
Date: Fri, 23 Oct 2015 01:04:05 +0200
[Message part 1 (text/plain, inline)]
On 21.10.2015 18:38, Ludovic Courtès wrote:
>> Looking around a bit, I found [0]. Apparently someone had the same
>> issue, though discussion broke off, because the reporter wasn't able
>> to provide the build log, so here it is for gcc-cross-boot0 (last 200
>> lines). Maybe we can just lift off where the previous discussion died.
> Is this deterministic?  That is, does it happen again if you rerun ‘guix
> build zile’ or something like that?
Yes, "guix build zile" fails again at GCCs build. I attached the build 
log just to be sure.
>> Makefile:2107: recipe for target 's-attrtab' failed
>> make[2]: *** [s-attrtab] Killed
> The “Killed” here suggests an out-of-memory condition.  Does
> ‘dmesg | tail’ reveal something like that?
>
> How much memory does this machine have?
It got 4GB of RAM but none of swap. dmesg really shows something, please 
see attachment. I'll try hooking up some swap and see how it goes.

I'm curious: How did you compile gcc in the past, where resources were 
even more scarce? Did you always have a good load of swap for it to 
succeed? I remember the rule "swap is 2 times ram", though in recent 
years some are convinced that it worn off given the ever bigger RAM.

Aljosha
[2kj5a59dymn0dhg0v09xqhc4hsxgsv-gcc-4.9.3.drv (text/plain, attachment)]
[dmesg.log (text/x-log, attachment)]

This bug report was last modified 9 years and 212 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.