re: lib/60324: unwind.h build race condition
"matthew green via gnats" <[email protected]>
| Newsgroups | gmane.os.netbsd.bugs |
|---|---|
| Message-ID | <[email protected]> |
The following reply was made to PR lib/60324; it has been noted by GNATS. From: matthew green <[email protected]> To: [email protected], [email protected] Cc: [email protected], [email protected], [email protected] Subject: re: lib/60324: unwind.h build race condition Date: Thu, 09 Jul 2026 11:11:26 +1000 sorry, i'd missed this PR being submitted. i think the fix you commited is fine, and nicely found on what is likely going wrong (i'm convinced by your analysis.) maybe the real fix is to not enter this subdirectory twice in this same high-level .WAIT group at all. there are a few subdirs we traverse twice but perhaps we should stop doing that entirely. eg, src/Makefile had (the first line would have a .WAIT now): _SUBDIR=3D tools .WAIT lib _SUBDIR+=3D include external crypto/external bin and src/external/Makefile has: SUBDIR+=3D amdgpu-firmware apache2 atheros broadcom bsd cddl gpl2 gpl3 his= torical and src/external/gpl3/Makefile has: SUBDIR+=3D ${EXTERNAL_GCC_SUBDIR} etc., where it ends up entering libgcc from multiple parts of the same .WAIT segment. this isn't the only one, but maybe it's the only one that has a build-a-file conflict. not doing this would mean we could take the new .WAIT away again. it might be nice to still allow this with some variable set, since eg, i will cleandir in src/external/gpl3/gcc and rebuild just that sometimes when i'm testing gcc stuff, but i'm fine for this to be a special thing you have to ask for.) thanks. .mrg.