bug#48273: Icedove 78.10.0 build stuck at 'unpack' phase

[Mark H Weaver <mhw@netris.org>]

Hi Leo,

Leo Famulari <leo@famulari.name> writes:

> On Tue, May 11, 2021 at 12:21:33AM +0000, bo0od wrote:
>> Since you said these are giving 2 different readings then the issue is with
>> timing, So i kept it for like 24 hour (or more) and now i hope the log make
>> more sense since there are too many fail,warnings..etc
>
> I see on line 422929 this error:
>
> 231:25.01 g++: internal compiler error: Killed (program cc1plus)

Thanks, Leo, for finding the relevant line and attaching the build log.

> That usually means that you ran out of memory / RAM.

Agreed.  Note that I've never actually tried to build 'icedove' from
source, so I don't know if 4GB RAM + 8GB swap is enough to build it.

It might possibly be relevant that our 'icecat' package uses a different
build method than our 'icedove' package.  Our 'icecat' package uses the
GNU build system approach of running './configure' and 'make', whereas
'icedove' uses the Mozilla-preferred approach of creating a '.mozconfig'
file and running './mach'.

These different approaches might result in different numbers of
concurrent build processes being run during the build.  On my system
(Thinkpad X200, Core 2 Duo), the 'icecat' build system runs 2 processes
concurrently during the build.  This is the most that my 4 GB of RAM can
support, and even then I must shut down other memory intensive processes
(such as modern web browsers) in order for it to work.

When building 'icedove', after the 'build' phase has started compiling
code with GCC or Rustc, can you see how many compile jobs are running at
once?  If it's more than 2, that's likely to be the problem.

If 'icedove' does not honor the Guix --cores option, that should be
fixed.

     Regards,
       Mark

-- 
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about <https://stallmansupport.org>.