[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]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=233735

--- Comment #10 from Mark Millard <marklmi26-fbsd at yahoo.com> ---
(In reply to Mark Millard from comment #9)

Some experiments with a command adjusted to be tolerable
to gcc10 (just to find the include handling behavior) and
using -v that shows the include paths shows:

#include "..." search starts here:
#include <...> search starts here:
 .
 /usr/13_0R-src/sys
 /usr/13_0R-src/sys/contrib/ck/include
 /usr/13_0R-src/sys/contrib/libfdt
 /usr/13_0R-src/sys/contrib/device-tree/include

and gets:

In file included from /usr/13_0R-src/sys/sys/param.h:99,
                 from /usr/13_0R-src/sys/kern/genoffset.c:35:
/usr/13_0R-src/sys/sys/types.h:46:10: fatal error: machine/endian.h: No such
file or directory
   46 | #include <machine/endian.h>
      |          ^~~~~~~~~~~~~~~~~~
compilation terminated.

Given the search path listed, the failure makes sense.

It appears that:

--sysroot=/usr/obj/BUILDs/13_0R-CA7-nodbg-clang/usr/13_0R-src/arm.armv7/tmp

is not ending up contributing to the path list. Same
when I added a -isysroot for the path.

Notably I have:

# zfs list 
NAME                                  USED  AVAIL     REFER  MOUNTPOINT
zroot                                56.2G   137G       96K  /zroot
zroot/BUILDs                         25.3G   137G      120K  /usr/obj/BUILDs
. . .
zroot/BUILDs/13_0R-CA7-nodbg-clang   5.04G   137G     5.04G 
/usr/obj/BUILDs/13_0R-CA7-nodbg-clang
. . .

but there is also:

. . .
zroot/usr/13_0R-src                  2.02G   137G     2.02G  /usr/13_0R-src
. . .

and paths with a /usr/13_0R-src prefix are showing up.
(But that does not involve two levels of zfs file systems,
however.)

It does appear that both system-clang and gcc10 are ending
up with similar behavior for the sysroot include file
handling during this failure. (I've not rebooted yet.)
So either I've got an operator-error problem that I've not
noticed or the problem is not specific to system-clang.

(I used gcc10 because I'm not aware of a way to have
clang report its include search path sequence, just
its library search path sequence.)

-- 
You are receiving this mail because:
You are the assignee for the bug.