Date: Fri, 30 Apr 2021 05:40:23 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 233735] Possible build race: genoffset.o /usr/src/sys/sys/types.h: error: machine/endian.h: No such file or directory Message-ID: <bug-233735-227-iT2o2H11fK@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-233735-227@https.bugs.freebsd.org/bugzilla/> References: <bug-233735-227@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D233735 --- Comment #13 from Mark Millard <marklmi26-fbsd@yahoo.com> --- (In reply to Mark Millard from comment #12) [You can skip to the # pwd and later lines to just see what the below lead to discovering. (- is new from-scratch rebuild and + is older rebuild failure that was not for a from scratch rebuild)] Well, the prefix differences in the .o.meta file look like: CWD /usr/obj/BUILDs/13_0R-CA7-nodbg-clang/usr/13_0R-src/arm.armv7/sys/GENERIC-N= ODBG-CA7 TARGET genoffset.o -OODATE /usr/13_0R-src/sys/kern/genoffset.c opt_global.h machine +OODATE /usr/13_0R-src/sys/kern/genoffset.c opt_global.h -- command output -- +In file included from /usr/13_0R-src/sys/kern/genoffset.c:35: +In file included from /usr/13_0R-src/sys/sys/param.h:99: +/usr/13_0R-src/sys/sys/types.h:46:10: fatal error: 'machine/endian.h' file= not found +#include <machine/endian.h> + ^~~~~~~~~~~~~~~~~~ +1 error generated. +*** Error code 1 + . . . Both new and old show the likes of: -R 94818 ./opt_global.h and: +R 53671 ./opt_global.h but only new shows lines with "machine": -R 94818 /usr/13_0R-src/sys/sys/types.h -R 94818 ./machine/endian.h -R 94818 /usr/13_0R-src/sys/sys/_types.h -R 94818 ./machine/_types.h . . . -R 94818 /usr/13_0R-src/sys/sys/priority.h -R 94818 ./machine/param.h -R 94818 ./machine/_align.h -R 94818 /usr/13_0R-src/sys/sys/assym.h . . . -R 94818 /usr/13_0R-src/sys/sys/runq.h -R 94818 ./machine/runq.h -R 94818 /usr/13_0R-src/sys/sys/resource.h -R 94818 /usr/13_0R-src/sys/sys/sigio.h -R 94818 /usr/13_0R-src/sys/sys/signal.h -R 94818 ./machine/_limits.h -R 94818 ./machine/signal.h -R 94818 /usr/13_0R-src/sys/sys/signalvar.h . . . -R 94818 /usr/13_0R-src/sys/sys/_rmlock.h -R 94818 ./machine/pcpu.h -R 94818 ./machine/pcpu_aux.h -R 94818 /usr/13_0R-src/sys/sys/systm.h -R 94818 ./machine/atomic.h -R 94818 /usr/13_0R-src/sys/sys/atomic_common.h -R 94818 ./machine/armreg.h -R 94818 ./machine/atomic-v6.h -R 94818 /usr/13_0R-src/sys/sys/_atomic_subword.h -R 94818 ./machine/cpufunc.h -R 94818 /usr/13_0R-src/sys/sys/stdint.h -R 94818 ./machine/_stdint.h -R 94818 /usr/13_0R-src/sys/sys/kpilite.h -R 94818 /usr/13_0R-src/sys/sys/libkern.h -R 94818 /usr/13_0R-src/sys/sys/ucontext.h -R 94818 ./machine/ucontext.h -R 94818 /usr/13_0R-src/sys/sys/_ucontext.h . . . -R 94818 /usr/13_0R-src/sys/sys/_domainset.h -R 94818 ./machine/proc.h -R 94818 ./machine/utrap.h -R 94818 ./machine/cpu.h -R 94818 ./machine/frame.h -R 94818 ./machine/cpu-v6.h -R 94818 ./machine/cpuinfo.h -R 94818 ./machine/sysreg.h -M 94818 'genoffset-ee1f8ac4.o.tmp' 'genoffset.o' -X 94818 0 0 -X 94815 0 0 -# Stop 1619758457.627651 The paths with "machine" show ./ prefixes, not the explicit path I had expected. And that leads to my incorrect expectations and to the explanation for the behavior: # pwd /usr/obj/BUILDs/13_0R-CA7-nodbg-clang/usr/13_0R-src/arm.armv7/sys # ls -Tld */machine lrwxr-xr-x 1 root wheel 24 Apr 21 03:39:09 2021 GENERIC-NODBG-CA7-older/machine -> /usr/src/sys/arm/include lrwxr-xr-x 1 root wheel 30 Apr 29 21:54:15 2021 GENERIC-NODBG-CA7/machin= e -> /usr/13_0R-src/sys/arm/include The older tree links to an absolute path that starts with /usr/src/ (from before my rename). So "machine" was present locally but pointed to a path that had nothing to reference. That is enough to apparently block the compiler from looking via --sysroot's path. That probably also gets back to the .o.meta file difference: -OODATE /usr/13_0R-src/sys/kern/genoffset.c opt_global.h machine +OODATE /usr/13_0R-src/sys/kern/genoffset.c opt_global.h where the older not-from-scratch rebuild does not list "machine" but the from-scratch build's one does. buildworld, by contrast, does not produce such absolute paths that reach outside a fairly localized sub tree (by comparison). So it survived the rename in a way that did not mess up the rebuild. I've no clue if the original intermittent problem was with creating or using or replacing such symbolic links (whatever the content of the links). Back then I never even thought to look for this type of "machine" usage. --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-233735-227-iT2o2H11fK>