[Top][All Lists]

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

Re: obscure failures when RAM is low

From: Daniel Pocock
Subject: Re: obscure failures when RAM is low
Date: Mon, 01 Jun 2015 11:17:35 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.6.0

On 31/05/15 03:23, Zack Weinberg wrote:
> "Internal compiler error: Killed (program cc1plus)" almost always
> indicates that the compiler-proper ran the computer out of memory and
> triggered the OOM killer.  Perhaps you should file a bug on GCC asking
> for the driver to mention this possibility when it detects that the
> compiler-proper has received a SIGKILL.
> Perhaps you should also file a bug on libtool asking for it to
> suppress compiler output with -w instead of redirecting it to
> /dev/null (at least, when it knows it's driving GCC).  In the
> alternative, perhaps you should develop some Automake extensions that
> would *finally* allow us to take libtool out back and shoot it.

I agree the GCC error is not an autotools fault and the libtool thing is
not something I can roll my sleeves up and fix right now

That is why I was asking about a way for configure to do a basic sanity
test on available memory.  Maybe my question wasn't clear enough.  I
don't expect configure to magically know how much memory is needed, just
a simple test where the developer can suggest some fixed value (e.g.
1GB) and the configure script stops if there is less.

I also fully understand this is not a bulletproof solution, other
processes could still take memory after the build starts running and it



reply via email to

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