Module compiles looking in /usr/src when alternate src tree is in use [actually the arm_neon.h and stdint.h issue]
bob prohaska
fbsd at www.zefox.net
Mon Apr 9 05:08:47 UTC 2018
On Sun, Apr 08, 2018 at 09:51:19PM -0700, Mark Millard wrote:
> Rodney W. Grimes freebsd-rwg at pdx.rh.CN85.dnsmgr.net wrote on
> Mon Apr 9 03:54:50 UTC 2018 :
>
> > Something for some reason included arm_neon.h?
>
>
> # grep -r arm_neon.h /usr/src/sys/ | more
> /usr/src/sys/crypto/armv8/armv8_crypto_wrap.c:#include <arm_neon.h>
>
> arm_neon.h is something that the kernel source itself has a reference
> to. [But the stdint.h that was in the error messages was found were
> the it should not exist as far as I can tell, see below.]
>
> # find /usr/src -name .svn -prune -o -name arm_neon.h -print
>
> finds nothing. But . . .
>
> # find /usr/lib -name arm_neon.h -print
> /usr/lib/clang/6.0.0/include/arm_neon.h
>
> This matches the error message report and is the only
> copy around in the system areas to find. (Ignoring
> ports materials and /usr/local/ .)
>
> In turn that arm_neon.h has:
>
> # grep stdint.h /usr/lib/clang/6.0.0/include/arm_neon.h
> #include <stdint.h>
>
> Looking in a tree that I have (from an amd64 -> arm64 cross
> build for what is a Cortex-A53 intended use):
>
> /usr/obj/DESTDIRs/clang-cortexA53-installworld/
>
> were I did an installworld for arm64:
>
> # find /usr/obj/DESTDIRs/clang-cortexA53-installworld -name stdint.h
> /usr/obj/DESTDIRs/clang-cortexA53-installworld/usr/include/c++/v1/stdint.h
> /usr/obj/DESTDIRs/clang-cortexA53-installworld/usr/include/c++/v1/tr1/stdint.h
> /usr/obj/DESTDIRs/clang-cortexA53-installworld/usr/include/sys/stdint.h
> /usr/obj/DESTDIRs/clang-cortexA53-installworld/usr/include/stdint.h
>
> There is no stdint.h under that tree's /usr/lib/ area:
>
> /usr/obj/DESTDIRs/clang-cortexA53-installworld/usr/lib/
>
> was not listed anywhere.
>
> For reference relative to arm_neon.h and this tree:
>
> # find /usr/obj/DESTDIRs/clang-cortexA53-installworld -name arm_neon.h | more
> /usr/obj/DESTDIRs/clang-cortexA53-installworld/usr/lib/clang/6.0.0/include/arm_neon.h
>
> I conclude that:
>
> /usr/lib/clang/6.0.0/include/stdint.h
>
> should not have been created in the first place.
>
> [Does that stdint.h have file-system dates/times matching
> the other files from the build? Or does it look to be
> mismatched and possibly just needs to be deleted?]
>
On my RPi3
root at www:/usr/src # ls -l /usr/lib/clang/6.0.0/include/stdint.h
-rw-r--r-- 1 root wheel 23387 Feb 16 07:37 /usr/lib/clang/6.0.0/include/stdint.h
Every other file in that directory is dated January 22nd.
>
> For reference, all the above is based on source for head -r332293:
>
> # uname -apKU
> FreeBSD FBSDFSSD 12.0-CURRENT FreeBSD 12.0-CURRENT r332293M amd64 amd64 1200061 1200061
>
> # svnlite info /usr/src | grep "Re[plv]"
> Relative URL: ^/head
> Repository Root: svn://svn.freebsd.org/base
> Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
> Revision: 332293
> Last Changed Rev: 332293
>
>
> I do not have an arm64 system that is anywhere near up to
> date at this time so the above evidence is not from a
> self-hosted build: My context is not a full-match.
>
Looks like it's close enough 8-)
Removing /usr/lib/clang/6.0.0/include/stdint.h has allowed make kernel
to proceed past its former point of failure.
Thank you!
bob prohaska
More information about the freebsd-current
mailing list