Re: Module compiles looking in /usr/src when alternate src tree is in use

> On Sun, Apr 08, 2018 at 05:40:55PM -0700, Rodney W. Grimes wrote:
> > > On Sun, Apr 08, 2018 at 12:00:52PM -0700, Rodney W. Grimes wrote:
> > > > I am having a compile time issue for a patched that compiled fine on my
> > > > r329294 system, but now failes to compile with what looks like a wrong
> > > > header being included.
> > > > 
> > > Might this be a cousin to the problem reported at
> > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227274 ?
> > > 
> > > In that kernel compile (on an RPi3) the compiler complains
> > > 
> > > 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;
> > > 
> > > The reference to /usr/lib/clang/... seems a bit strange; isn't a major 
> > > purpose of the kernel build procedure to minimize reliance on the
> > > host system's (already-stale) software?
> > 
> > Are you building in /usr/src, or are your sources located some place else?
> > 
> This is a straightforward self-hosted build on an RPi3. Sources are in
> /usr/src. There are no modifications to the source directories. 
> 
> 
> 
> > Really need the log that includes the cc command line, as that has the
> > tell tell -I/usr/src/sys in it.  That component is totally bogus!  At
> > no time should a src tree rooted at /usr/src-topo be trying to use files
> > from /usr/src/.
> > 
> Should files _outside_ /usr/src or /usr/obj _ever_ be referenced during
> a world or kernel build? I thought the answer was "no".  

Well if your sources are at /usr/src, then rarely, but there are leaks
that have happend where /usr/include is refenced.

> The line leading up to the error message is:
> 
I am going to split this line up at -I

> --- armv8_crypto_wrap.o ---
> cc -target aarch64-unknown-freebsd12.0 --sysroot=/usr/obj/usr/src/arm64.aarch6
> 4/tmp -B/usr/obj/usr/src/arm64.aarch64/tmp/usr/bin -c -O3 -pipe -fno-strict-al
> iasing -Werror -D_KERNEL -DKLD_MODULE -DHAVE_KERNEL_OPTION_HEADERS -include /u
> sr/obj/usr/src/arm64.aarch64/sys/GENERIC-NODEBUG/opt_global.h 
-I. 
-I/usr/src/sys -fno-common -g -fPIC 
  ^^^^^^^^^^^  Since your sources are /usr/src, this is fine, my problem is
that I am compiling from /usr/src-topo, and I have patches, and these patches
are NOT in /usr/src, but I have to put *some* of them in /usr/src to make
my /usr/src-topo compile.  SO something is broken, but I do not think
that is what is effecting you.

-I/usr/obj/usr/src/arm64.aarch64/sys/GENERIC-NODEBUG -
> ffixed-x18 -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundan
> t-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-ar
> ith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kpri
> ntf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -W
> no-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equ
> ality -Wno-error-unused-function -Wno-error-pointer-sign -Wno-error-shift-nega
> tive-value -Wno-error-address-of-packed-member -std=iso9899:1999  -Werror   -m
> arch=armv8-a+crypto /usr/src/sys/crypto/armv8/armv8_crypto_wrap.c
> 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:
> 
> There's a "-I/usr/src/sys" in the fourth line, which in my case makes sense,
> but where does the reference to /usr/lib/clang/.... come from, and is it 
> appropriate?

Something for some reason included arm_neon.h?  And I do not know why that
was found at /usr/lib/clang/...  Could it be something in that opt_global.h?
Or something trigger by the -target arch, or the -m armv8?


> > > If the two problems are related, should the subject line on the bug
> > > report be changed?
> > 
> > It could be, but more info would be needed.
> > 
> Please let me know what additional information is needed. 

Your problem is not the same as mine.  You are compiling from /usr/src,
which hides the problem I am having.


-- 
Rod Grimes                                                 rgrimes_at_freebsd.org