Re: Resolved: devel/llvm13 build: "ninja: build stopped: subcommand failed"
Date: Mon, 15 Aug 2022 03:26:30 UTC
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