On 12/1/20 12:05 PM, Richard W.M. Jones wrote:
This Rawhide build:
https://koji.fedoraproject.org/koji/taskinfo?taskID=56536942
seems to have failed because of LTO running out of memory on armv7.
The error is:
lto1: out of memory allocating 104 bytes after a total of 2966994944 bytes
lto-wrapper: fatal error: gcc returned 1 exit status
compilation terminated.
/usr/bin/ld: error: lto-wrapper failed
collect2: error: ld returned 1 exit status
In fact I had noticed before that this binary takes quite a long time
to compile with LTO even on x86-64. It's not especially large (7 MB
with debug symbols, 2.2 MB fully stripped).
But I suppose one thing which is special about it is that it's a
"mixed" C and OCaml binary, but as far as I know the OCaml objects
should be effectively ignored from an LTO point of view.
I can't see why it should need to allocate 2GB(!) in order to LTO it.
Note that
the LTO phase is parallelized, so there may be multiple
compilations/links in flight which can stress a builder with low
physical or virtual memory.
What I've been pondering for this is to have a macro that a package
could set to indicate that throttling is needed. Probably as a first
cut it would throttle to half of what smp_mflags allows. But that's
just a guess as to where to start.
In the immediate term go ahead and disable lto via the usual mechanism
and a comment that it's being done because of memory requirements.
%global _lto_cflags %{nil} or %define _lto_cflags %{nil}
I've got a spec file scanner that will flag the package as opting out.
Knowing that I can use it as a testcase for the throttling mechanism.
jeff