* Jeff Law:
Actually, isn't it "just" 234MB. Still I'm
surprised why that failed. Do we
have more than one build running at a time on those boxes?
It's a 32-bit build. I assume it's not the first large allocation.
(FWIW, GDB always prints “virtual memory exhausted”, even if the malloc
failure has a different cause.)
Does LTO produce more complicated debugging information? Then maybe
disabling LTO on armhfp is a workaround. There's also a way to disable
debuginfo package generation altogether, something along these lines
(untested):
%define debug_package %{nil}
%define __debug_install_post %{nil}
%global __debug_package %{nil}
%undefine _debugsource_packages
%undefine _debuginfo_subpackages
%undefine _unique_debug_names
%undefine _unique_debug_srcs
Thanks,
Florian