Bug 220125 - head -r320059 and head -r324743 (e.g.) arm64: buildkernel after kernel-toolchain: crypto/armv8/armv8_crypto_wrap.c compile fails with .../lib/clang/[45].0.0/include/arm_neon.h: fatal error: 'stdint.h' file not found
Summary: head -r320059 and head -r324743 (e.g.) arm64: buildkernel after kernel-toolch...
Status: New
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: CURRENT
Hardware: arm64 Any
: --- Affects Some People
Assignee: freebsd-bugs mailing list
: 223229 (view as bug list)
Depends on:
Reported: 2017-06-19 06:22 UTC by Mark Millard
Modified: 2018-07-16 15:50 UTC (History)
3 users (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Mark Millard 2017-06-19 06:22:44 UTC
[No matter if kernel-toolchain is modified to create a stdint.h (plus
whatever might go with it) vs. if arm_neon.h is made to avoid including
stdint.h this is a toolchain issue from what I can tell.]

Doing a kernel-toolchain build establishes:

# ls -dlT /usr/obj/cortexA53dbg_clang/arm64.aarch64/usr/src/include/*
drwxr-xr-x  2 root  wheel  2 Jun 18 22:14:57 2017 /usr/obj/cortexA53dbg_clang/arm64.aarch64/usr/src/include/arpa
drwxr-xr-x  2 root  wheel  2 Jun 18 22:14:59 2017 /usr/obj/cortexA53dbg_clang/arm64.aarch64/usr/src/include/gssapi
drwxr-xr-x  2 root  wheel  2 Jun 18 22:14:57 2017 /usr/obj/cortexA53dbg_clang/arm64.aarch64/usr/src/include/protocols
drwxr-xr-x  2 root  wheel  2 Jun 18 22:14:58 2017 /usr/obj/cortexA53dbg_clang/arm64.aarch64/usr/src/include/rpc
drwxr-xr-x  2 root  wheel  2 Jun 18 22:14:58 2017 /usr/obj/cortexA53dbg_clang/arm64.aarch64/usr/src/include/rpcsvc
drwxr-xr-x  2 root  wheel  2 Jun 18 22:14:59 2017 /usr/obj/cortexA53dbg_clang/arm64.aarch64/usr/src/include/xlocale

which excludes the following that a buildworld establishes
(shown from a different build):

# find /usr/obj/cortexA53_clang/ -name stdint.h -print | more

But /usr/src/sys/crypto/armv8/armv8_crypto_wrap.c includes <...>/lib/clang/4.0.0/include/arm_neon.h which in turn includes
stdint.h via (this was an attempted debug build of the

#include <stdint.h>

The overall combination prevents doing a buildkernel after
having done kernel-toolchain without ever having done
buildworld. In other words: buildworld is required before
buildkernel can finish.

--- armv8_crypto_wrap.o ---
In file included from /usr/src/sys/crypto/armv8/armv8_crypto_wrap.c:46:
/usr/obj/cortexA53dbg_clang/arm64.aarch64/usr/src/tmp/usr/bin/../lib/clang/4.0.0/include/arm_neon.h:31:10: fatal error: 'stdint.h' file not found
#include <stdint.h>
--- all_subdir_armv8crypto ---
*** [armv8_crypto_wrap.o] Error code 1

make[4]: stopped in /usr/src/sys/modules/armv8crypto
.MAKE.MODE='meta missing-filemon=yes missing-meta=yes silent=yes verbose'
_ERROR_CMD='cc -mcpu=cortex-a53 -target aarch64-unknown-freebsd12.0 --sysroot=/usr/obj/cortexA53dbg_clang/arm64.aarch64/usr/src/tmp -B/usr/obj/cortexA53dbg_clang/arm64.aarch64/usr/src/tmp/usr/bin -c -O3 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj/cortexA53dbg_clang/arm64.aarch64/usr/src/sys/GENERIC-DBG/opt_global.h -I. -I/usr/src/sys -fno-common -g -fPIC -I/usr/obj/cortexA53dbg_clang/arm64.aarch64/usr/src/sys/GENERIC-DBG -ffixed-x18 -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -Wno-error-shift-negative-value -Wno-error-address-of-packed-member -std=iso9899:1999  -Werror   -march=armv8a+crypto /usr/src/sys/crypto/armv8/armv8_crypto_wrap.c; ctfconvert -L VERSION -g armv8_crypto_wrap.o;'
.MAKE.MAKEFILES='/usr/src/share/mk/sys.mk /usr/src/share/mk/local.sys.env.mk /usr/src/share/mk/src.sys.env.mk /root/src.configs/src.conf.cortexA53dbg-clang-bootstrap.amd64-host /usr/src/share/mk/bsd.mkopt.mk /usr/src/share/mk/bsd.suffixes.mk /root/src.configs/make.conf /usr/src/share/mk/local.sys.mk /usr/src/share/mk/src.sys.mk /dev/null /usr/src/sys/modules/armv8crypto/Makefile /usr/src/share/mk/bsd.kmod.mk /usr/src/sys/conf/kmod.mk /usr/src/share/mk/bsd.init.mk /usr/src/share/mk/bsd.opts.mk /usr/src/share/mk/bsd.cpu.mk /usr/src/share/mk/local.init.mk /usr/src/share/mk/src.init.mk /usr/src/sys/modules/armv8crypto/../Makefile.inc /usr/src/share/mk/bsd.own.mk /usr/src/share/mk/bsd.compiler.mk /usr/src/sys/conf/kern.opts.mk /usr/src/sys/conf/config.mk /usr/src/share/mk/bsd.links.mk /usr/src/share/mk/bsd.dep.mk /usr/src/share/mk/bsd.clang-analyze.mk /usr/src/share/mk/bsd.obj.mk /usr/src/share/mk/bsd.subdir.mk /usr/src/sys/conf/kern.mk'
.PATH='. /usr/src/sys/modules/armv8crypto /usr/src/sys/crypto/armv8 /usr/obj/cortexA53dbg_clang/arm64.aarch64/usr/src/sys/GENERIC-DBG'
1 error
Comment 1 Heinz N. Gies 2017-10-09 20:07:19 UTC
Still seeing the same
Comment 2 Heinz N. Gies 2017-10-10 09:10:07 UTC
I think Mark is right, it's a toolchain issue. Some googling later it looks like the issue is also present on non BSD systems that use NEON:

- http://discuss.redbear.cc/t/solved-stdint-h-not-found-during-compiling/1809
- https://answers.launchpad.net/gcc-arm-embedded/+question/291355
Comment 3 Heinz N. Gies 2017-10-10 09:19:18 UTC
This is most likely not a good solution but I could get the kernel to compile with this:

cp /usr/lib/include/stdint.h /usr/lib/clang/5.0.0/include/

it seems the /usr/lib/clang/5.0.0/include/ dir is where the file is missing
Comment 4 Mark Millard 2017-10-10 09:41:47 UTC
(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/. . .

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.
Comment 5 Heinz N. Gies 2017-10-10 09:53:07 UTC
I admit I've no idea what I'm doing ;), I'm just trying to bang my head around getting it to work. But what you say makes sense. I'm just happy it worked!
Comment 6 Mark Millard 2017-10-10 10:13:39 UTC
(In reply to Heinz N. Gies from comment #5)

If the build-host system type is the same as
the build-target system type and stdint.h
has not actually changed then


content may well actually be correct content.

But if stdint.h has changed (unlikely?) or
or the build is a cross build then the


content would more likely be wrong in some
way. But that way need not make the build
abort: it may just build something that is
wrong in some way.

In my examples such as:

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

the arm64.aarch64 is the build-target type.
(FreeBSD normally only produces such x.y
naming in the paths for cross builds.)
Comment 7 Heinz N. Gies 2017-10-10 10:17:39 UTC
Oh yes I wasn't cross compiling I was compiling a kernel on the host with slightly modified config (RCTL/VNET) so the stdint.h should be the same I guess.
Comment 8 Heinz N. Gies 2017-10-10 10:41:03 UTC
Hmm interesting,
I must have done something wrong. To double check, I ran build world again and then re-build the kernel after removing the stdint.h I copied, it build cleaninly

root@mystery-box:/usr/src # find . -name stdint.h

the file seems to be here now too.

I have the feeling it was a user error on my end for me.
Comment 9 Mark Millard 2017-10-10 18:37:00 UTC
(In reply to Heinz N. Gies from comment #8)

buildworld creates the files below in the
build directory tree involved:


but kernel-toolchain does not.

(My description has a ls of the wrong place
for the kernel-toolchain case.)

My report was that I had to use buildworld
when I should have been able to use just
kernel-toolchain instead. buildworld is a
much larger build.
Comment 10 Heinz N. Gies 2017-10-10 18:40:31 UTC
I see I totally missunderstood your ticket then, but you're right it'd make sense if the toolchain itself would do that!
Comment 11 Mark Millard 2017-10-10 19:34:05 UTC
Turns out that  johalun0 at gmail.com was not
using kernel-toolchain and so did not get the
same problem as I was reporting:

I needed to use buildworld instead of
kernel-toolchain to allow buildkernel
to work.

So back to Affects Only Me (for now?).
Comment 12 Mark Millard 2017-10-20 05:49:37 UTC

is another person running into this problem. So,
I've changed to AffectsSome People.

I've also updated the summary to mention head and clang 5
as well.
Comment 13 Mark Linimon freebsd_committer freebsd_triage 2017-10-25 05:35:28 UTC
*** Bug 223229 has been marked as a duplicate of this bug. ***
Comment 14 Mark Millard 2018-07-12 13:46:58 UTC
stdint.h was added to C in C99. It was intended to be the subset
of the older inttypes.h that was suitable for freestanding
environments. inttypes.h is defined to include stdint.h for
C99 and later as I remember (or to behave as-if it had?).

https://www.freebsd.org/cgi/man.cgi?build(7) is very explicit about what
is supposed to be the case relative to kernel-toolchain use:

     kernel-toolchain  Rebuild the tools needed	for kernel compilation.	 Use
		       this if you did not do a	buildworld first.

In other words: buildkernel is not intended to be self-contained/sufficient
according to the build documentation but buildworld should not be required.

Currently, overall, FreeBSD does not meet its own criteria for aarch64 relative
to kernel-toolchain .

As far as I can tell the issue can be summarized relative to kernel-toolchain
by saying that kernel-toolchain does not currently establish a (full)
freestanding C99 environment (relative to the headers anyway) but building clang
requires (at least) one of the missing items ( stdint.h ) for aarch64

In other words: I do not expect the blame would be with clang for this
issue, but with FreeBSD's build environment.
Comment 15 Mark Millard 2018-07-12 20:13:49 UTC
As was pointed out on the lists by Dimitry Andric, quoting about the
use of stdint.h . . .

. . . it's because sys/crypto/armv8/armv8_crypto_wrap.c includes
<arm_neon.h>, an intrinsics header, which in turn requires <stdint.h>.

This was introduced in https://svnweb.freebsd.org/changeset/base/308921,
and at the time resulted in similar build failures, specifically when
one attempted to build a new kernel, without building world or a new
toolchain first.
Comment 16 Mark Millard 2018-07-16 15:50:37 UTC
It looks like head -r336348 is intended to fix this issue.