[Bug 220125] head -r320059 (e.g.) arm64: buildkernel after kernel-toolchain: crypto/armv8/armv8_crypto_wrap.c compile fails with .../lib/clang/4.0.0/include/arm_neon.h: fatal error: 'stdint.h' file not found

[bugzilla-noreply at freebsd.org]

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

--- Comment #4 from Mark Millard <markmi at dsl-only.net> ---
(In reply to Heinz N. Gies from comment #3)

I do not expect that the working "buildworld"
puts a stdint.h in /usr/lib/clang/5.0.0/include/
so I do not expect that that is the right place.

I do expect that kernel-toolchain should put one
of more stdint.h files in place(s) that
buildworld does put such.

Note: It looks like my description's

# ls -dlT . . ./arm64.aarch64/usr/src/include/*

was incoherent. It should have exposed the areas that
were found to have stdint.h in the buildworld example:

. . ./arm64.aarch64/usr/src/tmp/usr/include/sys/stdint.h
. . ./arm64.aarch64/usr/src/tmp/usr/include/c++/v1/stdint.h
. . ./arm64.aarch64/usr/src/tmp/usr/include/c++/v1/tr1/stdint.h
. . ./arm64.aarch64/usr/src/tmp/usr/include/stdint.h

In general buildworld and the like should not be using
the live systems copies of files directly: they might
have been updated for the new version being built. So
normally they would be found under arm.aarch64/. . .
someplace.

Also clang/5.0.0/include/ probably does not get system
specific files normally but various architectures have
somewhat differing stdint.h content (such as for 32-bit
vs. 64-bit).

. . ./arm64.aarch64/usr/src/tmp/usr/include/stdint.h

is an example of a architecture specific path for
finding architecture specific content and so would
seem more likely.

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