Re: Resolved: devel/llvm13 build: "ninja: build stopped: subcommand failed"

On 2022-Aug-14, at 20:06, Tomoaki AOKI <junchoon@dec.sakura.ne.jp> wrote:

> On Sun, 14 Aug 2022 12:23:03 -0700
> Mark Millard <marklmi@yahoo.com> wrote:
> 
>> On 2022-Aug-14, at 11:07, Nuno Teixeira <eduardo@freebsd.org> wrote:
>> 
>>> I will follow https://docs.freebsd.org/en/books/handbook/book/#disks-growing and resize actual swap, but before that I will have to make sure that backups are ok in case of something goes wrong.
>>> 
>>> I've tooked a note about total swap <=60GB
>>> 
>>> . . .
>> 
>> 
>> I forgot an important question relative to the resource use
>> for building devel/llvm13 and later: do you need/want the
>> fortran compiler?
>> 
>> If not, you can disable the options: FLANG MLIR
>> (building FLAG would require building MLIR)
>> 
>> Then the build will be far less memory intensive
>> and take less time.
>> 
>> It had slipped my mind that my builds have these 2 options
>> disabled.
>> 
>> ===
>> Mark Millard
>> marklmi at yahoo.com
> 
> Is there any possibility that something alike Bug 264949 [1] for gcc11
> is happening?
> 
> For amd64, option GOLD (LTO support) is implied by default.
> If it causes LTO to be enabled for llvm13 build itself, and lld act as
> linker of gcc11, small TMPDIR would overflow.
> 
> gcc11 required at minimum 5GiB of free space on TMPDIR.
> (4GiB was insufficient.)
> 
> [1] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264949
> 

Nuno had a specific problem others have not reported:

QUOTE
I've tested it but it still fails:
---
pid 64502 (c++), jid 7, uid 65534, was killed: failed to reclaim memory
swap_pager: out of swap space
---
on a Lenovo Legion 5, 16GB RAM and 4GB swap.
END QUOTE

"was killed: failed to reclaim memory" and "swap_pager: out of swap
space" are not about "small TMPDIR overflow", at least not directly.

But if the tmpfs is of a form backed by RAM+SWAP, then the tmpfs
use can grow to contribute to causing reclaim problems and/or out of
swap space problems by competing for RAM+SWAP space.

Nuno reported having disabled such tmpfs use ( via USE_TMPFS=no in
/usr/local/etc/poudriere.conf ). I do not know if that status is
well confirmed or not. I've also no clue if WITH_DEBUG= might be
in use. (WITH_DEBUG needs to not be in use unless huge resources are
available.)

My amd64 tests indicate that something beyond the compiles/links
themselves was using significant RAM+SWAP in Nuno's context. I've
no clue what.

===
Mark Millard
marklmi at yahoo.com