https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=233735
--- Comment #13 from Mark Millard <[email protected]> --- (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-NODBG-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/machine -> /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. -- You are receiving this mail because: You are the assignee for the bug. _______________________________________________ [email protected] mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "[email protected]"
