Guix fails to build libreoffice

DoneSubmitted by Jan Wielkiewicz.
Details
4 participants
  • Jesse Gibbons
  • Ludovic Courtès
  • Tobias Geerinckx-Rice
  • Jan Wielkiewicz
Owner
unassigned
Severity
normal
J
J
Jan Wielkiewicz wrote on 22 Sep 2019 18:52
(address . bug-guix@gnu.org)
20190922185206.3ed64af4@interia.pl
Hi everyone!
I've recently tried to reconfigure my system, but after about 3 hoursof building libreoffice, the system froze for 2 hours and then guixthrew:
- '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 Duoprocessor, 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 iscorrect, the support for ARM have been removed from webkit-qt.I'm not sure if removing support for an achitecture is the rightsolution here - wouldn't it be better if Guix checked if the system ispowerful 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.cxxg++: 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 4make[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 2Backtrace: 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: 2term-signal: #f stop-signal: #f] 491200>)'.
---Jan Wielkiewicz
T
T
Tobias Geerinckx-Rice wrote on 22 Sep 2019 19:45
8736gorzqn.fsf@nckx
Jan,
Thanks for the report, and sorry you had to learn this the hard way.
Jan Wielkiewicz 写道:
Toggle quote (6 lines)> 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:
[…]
Toggle quote (5 lines)> 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.
Toggle quote (5 lines)> 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.
Toggle quote (4 lines)> 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.
Toggle quote (5 lines)> 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
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCgAdFiEEfo+u0AlEeO9y5k0W2Imw8BjFSTwFAl2Hs1AACgkQ2Imw8BjFSTypdA/+KpnOS1/x5PUCzVmyG10tJou499UtE92Ap+WH27NTD9y6KrynzzD5j8fq+4bHXNv7/59zddWijEv3ntAoGiZ03AADHBugAgsKPlqFhnC5OOsaSdMVf+dy660p3UulNI8BVaWzbAY+l4stlSqowoHA1XKsmNe3eL65WIPhuqf6wN+9kzIRLbI0eDtPR2fohVpJZb/vJc7/4k9KIHjXVoJJHxFgnyJqOf8ElO29HHhWOQlyTTPdYauhBNtRXMB3tIeEwXW64EIVSktDyVFJ2pAWnQPNDZRD64acbN0FijtaJwUzEAwk/u2ekDiwpdMhIFJOjhTchlMyyEH6SvXIp0rWsi5V0NBK9YjtHsvLY8hVVOe5MevxYOQlhihE5ZDfpMMYSps3GfPY/Trs1Bq7WApL9UWSQSE9xJ1P8e5DZAXBsN/qDwnXGruHFieKBlMVJ9/aMvFpaBy03RAzMBfMg+OyUXuJLZeBXfbJPi+IiEd83gkZ0cmaOufBgKk8Mj+LYAUcj0TKvVb+XWrXWaWfp5FAgLlE7/CCbwueNk8af42TQjw+j+VvwtOLvbNLAOnryyGuHF3p9wnP/27B8E4TQTFEnoCjt8yeN/gKCJ0X676II4X1J9v1fk3+6b9LG1IXjKURvXap+adPYu39W26Ge9G1Uf6d8FhWE8WvdnSlZW+r1co==ui78-----END PGP SIGNATURE-----
J
J
Jesse Gibbons wrote on 22 Sep 2019 20:28
db7edec055f648e5d94f43afd0c8b8a72b66737a.camel@gmail.com
On Sun, 2019-09-22 at 19:45 +0200, Tobias Geerinckx-Rice via Bug reports forGNU Guix wrote:
Toggle quote (43 lines)> 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 asswap and add (swap-devices) in the configuration.
T
T
Tobias Geerinckx-Rice wrote on 22 Sep 2019 20:41
(name . Jesse Gibbons)(address . jgibbons2357@gmail.com)
871rw8rx65.fsf@nckx
Jesse Gibbons 写道:
Toggle quote (8 lines)>> 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
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCgAdFiEEfo+u0AlEeO9y5k0W2Imw8BjFSTwFAl2HwFMACgkQ2Imw8BjFSTxu1A/+L9sh4fius8Trek4haD+3u1OyguK+hH1a3u6gLfm+1zstaI9ncctSrl9BHCAIgkAUqAqavwtaADiF0l5+m6PmT2QnpyzUV2gN95a8cD1ae3PFumM9zTx+3uBcg3V2DbpMoVpbifLKLgpI5ZNAcjFQ4hTiNZTXi25ERPimClKT8TsjZEQl5nxZWT5mDgMHCIHJtP/hhZZqWdL4l5su07HibD05nuhkcTCR4oS9qWjD/LynscSVJicqhAoBRV4cd6HXhLIl2/mDWS/N8dSvcHhZi2qt9iiU1MZ7dtcqVJgk8YnheS9ltmrH7n9WISAchbSenlEc5zMrFkfvhZ0RMZLMTLV4W/oH71uD4gXUEe/M2abfg5U1+yIrkMFmFzTsc9octCYqXuGhJuBu+onJt7lB0SYywIvu9b7C3fjyyijP+4x+5suTOKrG1bveUJzpuxfigC4kdIspa2Woxg56AXNAb8pPF4Gwe9lNGw/M3MV4do4kDa7byc3UlmHVVSNYSJyJuvZ1bt4mVyB7GiNl05S3rTsyAzM/+i7Adic3EFiqeUzLwUHaZO879AlKh1iSX1m/wuGWJISSrnMosUSZhZXICEU2PrKU0PzNeaLM+SInlk3gmm0nuWVlQmwe0hPCl/t6yEeo+p8eeDztd+rcyXUGfywl7EyeQK6xyjwzGt8OIuQ==lAPU-----END PGP SIGNATURE-----
T
T
Tobias Geerinckx-Rice wrote on 22 Sep 2019 20:44
(name . Jesse Gibbons)(address . jgibbons2357@gmail.com)
87zhiwqigo.fsf@nckx
Tobias Geerinckx-Rice 写道:
Toggle quote (3 lines)> 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
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCgAdFiEEfo+u0AlEeO9y5k0W2Imw8BjFSTwFAl2HwQgACgkQ2Imw8BjFSTxM2g/+Jfxn7HuIdjhUY6U+pczV5TAzEmW9hE+3V58d5U+/vfowg7ntXl7sPzT7z977ym25FdT4vvGao/H5iGMfnMgbgDd9RxrEqTHJ6o1j+4AJe280ARP7tcxUzCaXUGzcNgP4Dv3AUjb2SZQPoy/EoCncCGXU0V2PVWwsD+MvKOeQoXTTJ8MM9AYmaWDIeHy3ixdWQG1XwnnzKjyNg1bnSprugbi7qLrgLW4wrsrsxpENpvwutRkI1kilF+uuW3I0Qd7fL4eai7qwkXHxPdX6W/bVm0XnMBCQT/fmFGDZNgMj+rTucw4gLeBUl9SblbDMaEMbSfg3p1U71kjSSAp8fTDgoiPhNvUeKEsSgut3z3Na5IyYHsFAXWkHl3IyIfDY+bMbVjeWehg2AiBGC907+pr1E9EGJUDm26sLkUdw8Npx+IRd+3tUi9/ALvyU6QN1xZGlZ3+Ima7xhO18jEJnsOvOy3neAGxoUBnEdc1VQrs0XSzc62bA7VFuBsAw2DjGHvzFQqAdnLJHlxkjP7mJ8Bmt3N0IcXGNCGOfUIIfJUbrzmfk5Z7KQCXUtjAqproaJv77X1udfhrTyFLgdSmMAAiwHyWzoiYid935ez+g5i/PKqkarPC3szNrzslhcqv6l/GsTRYcoxxeKyEQbwroXEg3N+J9YTYz0yMCW0YChJ1MAIw==Pug+-----END PGP SIGNATURE-----
J
(name . Tobias Geerinckx-Rice)(address . me@tobias.gr)(address . 37482@debbugs.gnu.org)
20190923024535.39385299@kompiuter
On Sun, 22 Sep 2019 19:45:52 +0200Tobias Geerinckx-Rice <me@tobias.gr> wrote:
Toggle quote (4 lines)> 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.
Toggle quote (5 lines)> 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.
Toggle quote (11 lines)> 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 anddefined in the config.scm, but it didn't help. I'm also using Mate, butI can try without any DE. The only two things running in the backgroundwere Mate, mate terminal, Guix and %desktop-services.
Toggle quote (8 lines)> 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'tavailable?
Toggle quote (2 lines)>Or just how quickly it can destroy an SSD.
Even more fun... Waiting for a powerful libre computer from from theground, because running on old ThinkPads forever isn't the rightsolution.

Thanks for explanations and help,
Jan Wielkiewicz
L
L
Ludovic Courtès wrote on 26 Sep 2019 22:04
(name . Jan)(address . tona_kosmicznego_smiecia@interia.pl)
87y2yalt7h.fsf@gnu.org
Hello,
Jan <tona_kosmicznego_smiecia@interia.pl> skribis:
Toggle quote (3 lines)> 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’.
L
L
Ludovic Courtès wrote on 26 Sep 2019 22:05
control message for bug #37482
(address . control@debbugs.gnu.org)
87wodult6v.fsf@gnu.org
tags 37482 notabugclose 37482quit
J
Re: bug#37482: Guix fails to build libreoffice
(name . Ludovic Courtès)(address . ludo@gnu.org)
20190927200254.50801048@kompiuter
On Thu, 26 Sep 2019 22:04:50 +0200Ludovic Courtès <ludo@gnu.org> wrote:
Toggle quote (1 lines)> There’s no way to skip it. However, there are a couple of tricks:
What about adding an option to only download substitutes for olderdevices? I saw someone talking about such feature on the mailing list,don't know where exactly though.
Toggle quote (7 lines)> • 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
L
L
Ludovic Courtès wrote on 28 Sep 2019 11:31
(name . Jan)(address . tona_kosmicznego_smiecia@interia.pl)
875zlc22eh.fsf@gnu.org
Hello,
Jan <tona_kosmicznego_smiecia@interia.pl> skribis:
Toggle quote (7 lines)> 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 problematicsecurity-wise because you could easily find yourself installing olderversions with known vulnerabilities.
Thanks,Ludo’.
?
Your comment

This issue is archived.

To comment on this conversation send email to 37482@debbugs.gnu.org