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

From: Mark Millard <>
Date: Mon, 15 Aug 2022 03:26:30 UTC
On 2022-Aug-14, at 20:06, Tomoaki AOKI <> wrote:

> On Sun, 14 Aug 2022 12:23:03 -0700
> Mark Millard <> wrote:
>> On 2022-Aug-14, at 11:07, Nuno Teixeira <> wrote:
>>> I will follow 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
> 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]

Nuno had a specific problem others have not reported:

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.

"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

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