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 _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
