Attempts to build a kernel on RPI3 running -current at r331869 fail with --- all_subdir_armv8crypto --- In file included from /usr/src/sys/crypto/armv8/armv8_crypto_wrap.c:46: In file included from /usr/lib/clang/6.0.0/include/arm_neon.h:31: /usr/lib/clang/6.0.0/include/stdint.h:228:25: error: typedef redefinition with different types ('int16_t' (aka 'short') vs '__int_fast16_t' (aka 'int')) typedef __int_least16_t int_fast16_t; --- all_subdir_amr --- :> export_syms --- all_subdir_armv8crypto --- ^ /usr/obj/usr/src/arm64.aarch64/tmp/usr/include/stdint.h:51:25: note: previous definition is here typedef __int_fast16_t int_fast16_t; ^ In file included from /usr/src/sys/crypto/armv8/armv8_crypto_wrap.c:46: In file included from /usr/lib/clang/6.0.0/include/arm_neon.h:31: /usr/lib/clang/6.0.0/include/stdint.h:229:26: error: typedef redefinition with different types ('uint16_t' (aka 'unsigned short') vs '__uint_fast16_t' (aka 'unsigned int')) typedef __uint_least16_t uint_fast16_t; ^ /usr/obj/usr/src/arm64.aarch64/tmp/usr/include/stdint.h:56:26: note: previous definition is here typedef __uint_fast16_t uint_fast16_t; ^ In file included from /usr/src/sys/crypto/armv8/armv8_crypto_wrap.c:46: In file included from /usr/lib/clang/6.0.0/include/arm_neon.h:31: /usr/lib/clang/6.0.0/include/stdint.h:245:24: error: typedef redefinition with different types ('int8_t' (aka 'signed char') vs '__int_fast8_t' (aka 'int')) typedef __int_least8_t int_fast8_t; ^ /usr/obj/usr/src/arm64.aarch64/tmp/usr/include/stdint.h:50:24: note: previous definition is here typedef __int_fast8_t int_fast8_t; ^ In file included from /usr/src/sys/crypto/armv8/armv8_crypto_wrap.c:46: --- all_subdir_amr --- awk -f /usr/src/sys/conf/kmod_syms.awk amr_cam.kld export_syms | xargs -J% objcopy % amr_cam.kld --- all_subdir_armv8crypto --- In file included from /usr/lib/clang/6.0.0/include/arm_neon.h:31: /usr/lib/clang/6.0.0/include/stdint.h:246:25: error: typedef redefinition with different types ('uint8_t' (aka 'unsigned char') vs '__uint_fast8_t' (aka 'unsigned int')) typedef __uint_least8_t uint_fast8_t; ^ /usr/obj/usr/src/arm64.aarch64/tmp/usr/include/stdint.h:55:25: note: previous definition is here typedef __uint_fast8_t uint_fast8_t; ^ --- all_subdir_amr --- --- amr_cam.ko.full --- ld -m aarch64elf -Bshareable -znotext -d -warn-common --build-id=sha1 -o amr_cam.ko.full amr_cam.kld --- amr_cam.ko.debug --- objcopy --only-keep-debug amr_cam.ko.full amr_cam.ko.debug --- amr_cam.ko --- objcopy --strip-debug --add-gnu-debuglink=amr_cam.ko.debug amr_cam.ko.full amawk -f /usr/src/sys/conf/kmod_syms.awk amr_cam.kld export_syms | xargs -J% ob jcopy % amr_cam.kld --- all_subdir_armv8crypto --- In file included from /usr/lib/clang/6.0.0/include/arm_neon.h:31: /usr/lib/clang/6.0.0/include/stdint.h:246:25: error: typedef redefinition with different types ('uint8_t' (aka 'unsigned char') vs '__uint_fast8_t' (aka 'un signed int')) typedef __uint_least8_t uint_fast8_t; ^ /usr/obj/usr/src/arm64.aarch64/tmp/usr/include/stdint.h:55:25: note: previous definition is here typedef __uint_fast8_t uint_fast8_t; Replacement of /usr/src has no effect, removal of /usr/obj/usr/src has no effect. It's a little surprising to see buildkernel reference files outside /usr/src or /usr/obj, I thought the whole point of buildkernel was to segregate the new kernel environment from the old version of the system.
(In reply to Bob Prohaska from comment #0) Problems with arm_neon.h use for buildkernel have existed for some time, in that building kernel-toolchain first was not sufficient: buildworld was required instead. There are historical reports about this on the lists. At the time, arm_neon.h used a standard header that is not part of what kernel-toolchain established and FreeBSD did not define that that header would or should exist for such builds: the two sides simply mismatched, with a change of criteria needed on at least one side to make them match. So I had been using buildworld first even if only interested in building the kernel. But it has been some time since I last tried. I mention this as there may well be more than one issue to fix in this general area if now buildworld being first is not sufficient. I do not know if FreeBSD has tried to make /usr/lib/clang/6.0.0/include/* (or other such) FreeBSD compliant.
(In reply to Mark Millard from comment #1) Doesn't seem to matter whether buildworld or kernel-toolchain is used. I've tried it both ways. As you point out, there was an earlier problem when using kernel-toolchain in that a needed copy of stdint.h was missing, but that seems to have gone away.
The error persists in sources at r332164 using a kernel at r326343.
It was recognized (by Mark Millard) that /usr/lib/clang/6.0.0/include/stdint.h was somehow created in error. Deleting it seems to have fixed the bug.