Re: Module compiles looking in /usr/src when alternate src tree is in use [actually the arm_neon.h and stdint.h issue]

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