[Bug 233735] Possible build race: genoffset.o /usr/src/sys/sys/types.h: error: machine/endian.h: No such file or directory
bugzilla-noreply at freebsd.org
bugzilla-noreply at freebsd.org
Fri Apr 30 05:40:23 UTC 2021
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=233735
--- Comment #13 from Mark Millard <marklmi26-fbsd at 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-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.
More information about the freebsd-bugs
mailing list