Follow-up Comment #1, bug #64664 (project make): Hi Andreas,
[comment #0 original submission:] > This is not so much a bug report as a call for help... > > I'm trying to get Gentoo ported onto riscv32 using qemu usermode. Something is wrong... my chroot is ~90% functional, but a few programs behave erratic, among them bash (!) and make. > > I observe two oddities with make. > > * It seems to always only start one job no matter -j9 (annoying but harmless) > > * Sometimes, programs that should build perfectly (gcc, binutils) stop with a message: > make[3]: Leaving directory '/var/tmp/portage/sys-devel/gcc-13.2.1_p20230826/work/build/libiberty' > make[4]: Nothing to be done for 'all'. > make[3]: *** wait: No such file or directory. Stop. > make[3]: *** Waiting for unfinished jobs.... > > I seem to remember that I can circumvent this ^ by explicitly saying MAKEOPTS="-j1" > > Now, these are most likely *not* make bugs. > > However, any advice what in one of the underlying layers (glibc, qemu) might be failing would be very much appreciated... I think it's failing here: <https://git.savannah.gnu.org/cgit/make.git/tree/src/job.c#n757> But it's failing with ENOENT, which is not one of the documented errors for wait(2): ERRORS EAGAIN The PID file descriptor specified in id is nonblocking and the process that it refers to has not terminated. ECHILD (for wait()) The calling process does not have any unwaited‐for children. ECHILD (for waitpid() or waitid()) The process specified by pid (wait‐ pid()) or idtype and id (waitid()) does not exist or is not a child of the calling process. (This can happen for one’s own child if the action for SIGCHLD is set to SIG_IGN. See also the Linux Notes section about threads.) EINTR WNOHANG was not set and an unblocked signal or a SIGCHLD was caught; see signal(7). EINVAL The options argument was invalid. ESRCH (for wait() or waitpid()) pid is equal to INT_MIN. But I guess it's related to the inability to start more than one process. Maybe it thinks it has started more processes, and tries to wait for them, but there are no such entries? Cheers, Alex > > See also: > https://lists.gnu.org/archive/html/bug-bash/2023-09/msg00119.html > https://lists.gnu.org/archive/html/qemu-devel/2023-09/msg02894.html > (the qemu patch by LIU Zhiwei seems to make no difference, just testing this) _______________________________________________________ Reply to this item at: <https://savannah.gnu.org/bugs/?64664> _______________________________________________ Message sent via Savannah https://savannah.gnu.org/