Still seeing the same

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

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

(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.

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!

(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

/usr/lib/include/stdint.h

content may well actually be correct content.

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

/usr/lib/include/stdint.h

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.)

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.

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
./contrib/libstdc++/include/tr1/stdint.h
./contrib/llvm/tools/clang/lib/Headers/stdint.h
./contrib/libc++/include/stdint.h
./sys/sys/stdint.h

the file seems to be here now too.

I have the feeling it was a user error on my end for me.

(In reply to Heinz N. Gies from comment #8)

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

./contrib/libstdc++/include/tr1/stdint.h
./contrib/llvm/tools/clang/lib/Headers/stdint.h
./contrib/libc++/include/stdint.h
./sys/sys/stdint.h

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.

I see I totally missunderstood your ticket then, but you're right it'd make sense if the toolchain itself would do that!

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?).

https://lists.freebsd.org/pipermail/freebsd-arm/2017-October/016900.html

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 2017-10-25 05:35:28 UTC

*** Bug 223229 has been marked as a duplicate of this bug. ***

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
contexts.

In other words: I do not expect the blame would be with clang for this
issue, but with FreeBSD's build environment.

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.

It looks like head -r336348 is intended to fix this issue.

I've tried a from-scratch kernel-toolchain then
buildkernel in my head -r358510 context, targetting
my cortexA53dbg_clang style build again.

It works fine. So comment 16's report seems correct:
head -r336348 likely was the fix.