bug#37482: Guix fails to build libreoffice

bug#37482: Guix fails to build libreoffice

[Jan Wielkiewicz]

Hi everyone!

I've recently tried to reconfigure my system, but after about 3 hours
of building libreoffice, the system froze for 2 hours and then guix
threw:

- 'build' phasebuilder for
  `/gnu/store/ndibmh084iqmhv1ldv3fr3380mfk6qzg-libreoffice-6.1.5.2.drv'
  failed with exit code 1 build
  of /gnu/store/ndibmh084iqmhv1ldv3fr3380mfk6qzg-libreoffice-6.1.5.2.drv
  failed View build log at
  '/var/log/guix/drvs/nd/ibmh084iqmhv1ldv3fr3380mfk6qzg-libreoffice-6.1.5.2.drv.bz2'.
  guix system: error: build of
  `/gnu/store/ndibmh084iqmhv1ldv3fr3380mfk6qzg-libreoffice-6.1.5.2.drv'
  failed

My system is an old ThinkPad with 2GB of RAM and Intel Centrino Duo
processor, but I'm unsure if this was the cause of the build failing.
I saw some other packages have similar problems like, if my memory is
correct, the support for ARM have been removed from webkit-qt.
I'm not sure if removing support for an achitecture is the right
solution here - wouldn't it be better if Guix checked if the system is
powerful enough to handle building certain packages?

Here's the part of the log where it fails:

[build CXX] sc/source/core/data/colcontainer.cxx
[build CXX] sc/source/core/data/column.cxx
[build CXX] sc/source/core/data/column2.cxx
[build CXX] sc/source/core/data/column3.cxx
g++: internal compiler error: Killed (program cc1plus)
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
make[1]: ***
[/tmp/guix-build-libreoffice-6.1.5.2.drv-0/libreoffice-6.1.5.2/solenv/gbuild/LinkTarget.mk:293: /tmp/guix-build-libreoffice-6.1.5.2.drv-0/libreoffice-6.1.5.2/workdir/CxxObject/sc/source/core/data/column2.o] Error 4
make[1]: *** Deleting file
'/tmp/guix-build-libreoffice-6.1.5.2.drv-0/libreoffice-6.1.5.2/workdir/CxxObject/sc/source/core/data/column2.o'
make[1]: *** Waiting for unfinished jobs....
make: *** [Makefile:286: build] Error 2
Backtrace:
           4 (primitive-load "/gnu/store/8d49s04zpk9frpz9isawr8k4fma…")
In ice-9/eval.scm:
   191:35  3 (_ _)
In srfi/srfi-1.scm:
   863:16  2 (every1 #<procedure 5073a0 at /gnu/store/0npakqh7q9kfi…> …)
In /gnu/store/0npakqh7q9kfik8y0cc0vjqqpvnyv2h1-module-import/guix/build/gnu-build-system.scm:
   799:28  1 (_ _)
In /gnu/store/0npakqh7q9kfik8y0cc0vjqqpvnyv2h1-module-import/guix/build/utils.scm:
    616:6  0 (invoke _ . _)

/gnu/store/0npakqh7q9kfik8y0cc0vjqqpvnyv2h1-module-import/guix/build/utils.scm:616:6:
In procedure invoke:
Throw to key `srfi-34' with args `(#<condition &invoke-error [program:
"make" arguments: ("-j" "2" "build-nocheck") exit-status: 2
term-signal: #f stop-signal: #f] 491200>)'.

---
Jan Wielkiewicz

bug#37482: Guix fails to build libreoffice

[Tobias Geerinckx-Rice via Bug reports for GNU Guix]

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

Jan,

Thanks for the report, and sorry you had to learn this the hard 
way.

Jan Wielkiewicz 写道：
> I've recently tried to reconfigure my system, but after about 3 
> hours
> of building libreoffice, the system froze for 2 hours and then 
> guix
> threw:

[…]

> g++: internal compiler error: Killed (program cc1plus)
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See <http://gcc.gnu.org/bugs.html> for instructions.

This message and the freezing above is a tell-tale sign of OOM 
(out-of-memory).  If you check your dmesg or /var/log/messages at 
that time, I'm almost certain you'll see the OOM killer plot its 
dastardly deeds.

> My system is an old ThinkPad with 2GB of RAM and Intel Centrino 
> Duo
> processor, but I'm unsure if this was the cause of the build 
> failing.

You may be sure.

2 GiB of RAM is simply not enough to build many packages these 
days.  That's the world we live in.  There's nothing Guix can do 
to change that.

You can restrict the number of parallel builds and jobs by 
respectively passing --max-jobs=1 and --cores=1 to the daemon. 
You can make this permanent by setting (extra-options …) in your 
system configuration.

Even then, some complex executables will simply fail to link with 
so little RAM.

> I saw some other packages have similar problems like, if my 
> memory is
> correct, the support for ARM have been removed from webkit-qt.

I don't see how this is related to running out of RAM.  If 
webkit-qt is broken on ARM that's unfortunate, but it's better to 
mark it as such than failing to build it on 100% of ARM systems.

Your issue is different: the exact same libreoffice might have 
built fine if you had 4 GiB of RAM, or 3, or 5, or 2 with swap, 
but only if your weren't also running any (Guix or other) builds 
at the time, or watching a movie, or had the room thermostat 
turned up, or use Gnome 3, all beneath a gibbous moon.  All these 
things, and many more, will cause builds to fail or succeed 
‘randomly’.

The only way to know is to try.

> I'm not sure if removing support for an achitecture is the right
> solution here - wouldn't it be better if Guix checked if the 
> system is
> powerful enough to handle building certain packages?

I personally think the annoyances of ‘helpful’ warnings 
(=extremely inaccurate guesses) would far outweigh any purported 
benefit.

Kind regards,

T G-R

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

bug#37482: Guix fails to build libreoffice

[Jesse Gibbons]

On Sun, 2019-09-22 at 19:45 +0200, Tobias Geerinckx-Rice via Bug reports for
GNU Guix wrote:
> Jan,
> 
> Thanks for the report, and sorry you had to learn this the hard 
> way.
> 
> Jan Wielkiewicz 写道：
> > I've recently tried to reconfigure my system, but after about 3 
> > hours
> > of building libreoffice, the system froze for 2 hours and then 
> > guix
> > threw:
> 
> […]
> 
> > g++: internal compiler error: Killed (program cc1plus)
> > Please submit a full bug report,
> > with preprocessed source if appropriate.
> > See <http://gcc.gnu.org/bugs.html> for instructions.
> 
> This message and the freezing above is a tell-tale sign of OOM 
> (out-of-memory).  If you check your dmesg or /var/log/messages at 
> that time, I'm almost certain you'll see the OOM killer plot its 
> dastardly deeds.
> 
> > My system is an old ThinkPad with 2GB of RAM and Intel Centrino 
> > Duo
> > processor, but I'm unsure if this was the cause of the build 
> > failing.
> 
> You may be sure.
> 
> 2 GiB of RAM is simply not enough to build many packages these 
> days.  That's the world we live in.  There's nothing Guix can do 
> to change that.
> 
> You can restrict the number of parallel builds and jobs by 
> respectively passing --max-jobs=1 and --cores=1 to the daemon. 
> You can make this permanent by setting (extra-options …) in your 
> system configuration.
> 
> Even then, some complex executables will simply fail to link with 
> so little RAM.

You can get around too little RAM by using swap, correct? Partition ~8GB as
swap and add (swap-devices) in the configuration.

bug#37482: Guix fails to build libreoffice

[Tobias Geerinckx-Rice via Bug reports for GNU Guix]

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

Jesse Gibbons 写道：
>> Even then, some complex executables will simply fail to link 
>> with 
>> so little RAM.
>
> You can get around too little RAM by using swap, correct? 
> Partition ~8GB as
> swap and add (swap-devices) in the configuration.

Sure, I think I suggested that (I was serious about Gnome, too!). 
People tend to underestimate just how slow swap is by several 
orders of magnitude, though.

Not sure about LibreOffice, but I doubt you'll have much luck 
building, say, Chromium with 2 GiB of physical RAM, with or 
without swap — but I admit I haven't been crazy enough to try :-)

Another hack you can try is enabling 50% zstd zswap, but with 2 
GiB of RAM and such an old CPU that too is far out in diminishing 
returns territory.  It could just crash your kernel.

Kind regards,

T G-R

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

bug#37482: Guix fails to build libreoffice

[Tobias Geerinckx-Rice via Bug reports for GNU Guix]

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

Tobias Geerinckx-Rice 写道：
> People tend to underestimate just how slow swap is by several
> orders of magnitude, though.

Or just how quickly it can destroy an SSD.

Kind regards,

T G-R

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

bug#37482: Guix fails to build libreoffice

[Jan]

On Sun, 22 Sep 2019 19:45:52 +0200
Tobias Geerinckx-Rice <me@tobias.gr> wrote:

> 2 GiB of RAM is simply not enough to build many packages these 
> days.  That's the world we live in.  There's nothing Guix can do 
> to change that.

Sad, guess I have to buy more RAM.

> You can restrict the number of parallel builds and jobs by 
> respectively passing --max-jobs=1 and --cores=1 to the daemon. 
> You can make this permanent by setting (extra-options …) in your 
> system configuration.

Cool, didn't know about this option.

> Even then, some complex executables will simply fail to link with 
> so little RAM.
> 
> Your issue is different: the exact same libreoffice might have 
> built fine if you had 4 GiB of RAM, or 3, or 5, or 2 with swap, 
> but only if your weren't also running any (Guix or other) builds 
> at the time, or watching a movie, or had the room thermostat 
> turned up, or use Gnome 3, all beneath a gibbous moon.  All these 
> things, and many more, will cause builds to fail or succeed 
> ‘randomly’.

I actually have a 10GB sized swap file created on an SSD and
defined in the config.scm, but it didn't help. I'm also using Mate, but
I can try without any DE. The only two things running in the background
were Mate, mate terminal, Guix and %desktop-services.

> I personally think the annoyances of ‘helpful’ warnings 
> (=extremely inaccurate guesses) would far outweigh any purported 
> benefit.
> 
> Kind regards,
> 
> T G-R

Is there a way to skip building libreoffice, if the substitute isn't
available?

>Or just how quickly it can destroy an SSD.

Even more fun... Waiting for a powerful libre computer from from the
ground, because running on old ThinkPads forever isn't the right
solution.


Thanks for explanations and help,

Jan Wielkiewicz

bug#37482: Guix fails to build libreoffice

[Ludovic Courtès]

Hello,

Jan <tona_kosmicznego_smiecia@interia.pl> skribis:

> Is there a way to skip building libreoffice, if the substitute isn't
> available?

There’s no way to skip it.  However, there are a couple of tricks:

  • The ‘--dry-run’ option always shows what would be built or
    downloaded, so you can run, say, ‘guix upgrade --dry-run’ and see if
    libreoffice is among the things that would be built.

  • You can do ‘guix package -u . --do-not-upgrade=libreoffice’ to
    upgrade everything but packages whose name contains “libreoffice”.

HTH!

Ludo’.

bug#37482: Guix fails to build libreoffice

[Jan]

On Thu, 26 Sep 2019 22:04:50 +0200
Ludovic Courtès <ludo@gnu.org> wrote:

> There’s no way to skip it.  However, there are a couple of tricks:
What about adding an option to only download substitutes for older
devices? I saw someone talking about such feature on the mailing list,
don't know where exactly though.

>   • The ‘--dry-run’ option always shows what would be built or
>     downloaded, so you can run, say, ‘guix upgrade --dry-run’ and see
> if libreoffice is among the things that would be built.
> 
>   • You can do ‘guix package -u . --do-not-upgrade=libreoffice’ to
>     upgrade everything but packages whose name contains “libreoffice”.

Will use these options next time, thanks for the info.


Jan Wielkiewicz

bug#37482: Guix fails to build libreoffice

[Ludovic Courtès]

Hello,

Jan <tona_kosmicznego_smiecia@interia.pl> skribis:

> On Thu, 26 Sep 2019 22:04:50 +0200
> Ludovic Courtès <ludo@gnu.org> wrote:
>
>> There’s no way to skip it.  However, there are a couple of tricks:
> What about adding an option to only download substitutes for older
> devices?

That’s not possible in the general case.  Also, it would be problematic
security-wise because you could easily find yourself installing older
versions with known vulnerabilities.

Thanks,
Ludo’.