Created attachment 884146 [details] ps faux happened at tinderbox image 17.1_desktop_systemd-20240201-2315
Are you sure you had MAKEOPTS and NINJAFLAGS set? In your output I see e.g. ninja -v -j4 -l0 make -j4 V=1 which explain the multiple jobs. This package is using the cmake eclass so I'd expect it to be correct in the absence of any additional meddling.
(In reply to Michael Orlitzky from comment #1) > Are you sure you had MAKEOPTS and NINJAFLAGS set? In your output I see e.g. > > ninja -v -j4 -l0 > make -j4 V=1 > > which explain the multiple jobs. This package is using the cmake eclass so > I'd expect it to be correct in the absence of any additional meddling. I'd expect the 4 jobs, but a $ cat ~tinderbox/img/17.1_desktop_systemd-20240201-231503/etc/portage/package.env/00jobs */* j4 $ cat ~tinderbox/img/17.1_desktop_systemd-20240201-231503/etc/portage/env/ cflags_default j1 j4 nosandbox notest notmpfs test-fail-continue tinderbox@mr-fox /tmp/loadcheck.sh.d $ cat ~tinderbox/img/17.1_desktop_systemd-20240201-231503/etc/portage/env/j4 EGO_BUILD_FLAGS="-p 4" GO19CONCURRENTCOMPILATION=0 GOMAXPROCS=4 MAKEOPTS="$MAKEOPTS -j4" OMP_DYNAMIC=FALSE OMP_NESTED=FALSE OMP_NUM_THREADS=4 RUST_TEST_THREADS=4 RUST_TEST_TASKS=4 but a cut -c1-185 /tmp/loadcheck.sh.d/ps-faux-20240202-132031-42.txt | less shows few dozen of gcc jobs.
Hm, it looks like, ninja -v -j4 -l0 ... /usr/libexec/gcc/x86_64-pc-linux-gnu/13/lto-wrapper @/var/tmp/portage/sci-mathematics/flint-3.0.1/temp/ccBp6GPp.lto_wrapper_args make -f /var/tmp/portage/sci-mathematics/flint-3.0.1/temp/ccvwTQTT.mk -j32 all is to blame. I'm not very familiar with the lto-wrapper... is that a command that it generated? Note also that ninja doesn't support the GNU make jobserver (yet), so calling ninja from make or vice-versa will generally not work perfectly (https://github.com/ninja-build/ninja/issues/1139)
Maybe toolchain@ has some insight here? In short, it looks to me like the flint ebuild is running ninja with the correct number of jobs, but that ninja eventually executes gcc's lto-wrapper, and lto-wrapper is launching "make -j32". If so, this would be something to fix... I'm not sure where, but not in flint.
I took another look at this and am pretty sure I can't do anything about it. I'm not too familiar with lto-wrapper, but it looks like a coordination problem between ninja (flint) and make (lto-wrapper) that won't be solved until ninja supports the GNU make job server, or until we implement some other hack for lto-wrapper. toolchain@ this is your last chance to tell me I'm wrong :P
