Re: Module compiles looking in /usr/src when alternate src tree is in use
On 11/4/18 8:29 am, Rodney W. Grimes wrote: 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. You may find it helpful to do something like: make -dv -C sys/modules/vmm -V CFLAGS > /tmp/dvo 2>&1 egrep ':.PARSE|/usr/src/sys' /tmp/dvo | grep -B1 usr/src | more The arg to -V doesn't matter btw. You could narrow that down if you know what var -I/usr/src/sys is in (probably CFLAGS but you never know) the above should help find the makefile that is introducing the bogus -I Thank you, that does help narrow it down: (I backed up a vew lines from the first place I saw src/.) ... Global:.PARSEFILE = bsd.kmod.mk Global:.PARSEDIR = /usr/src-topo/share/mk Global:.PARSEFILE = bsd.kmod.mk Result[] of :U is "/usr/src/sys" Result[] of :U is "/usr/src/sys" Global:SYSDIR = ${:U/usr/src/sys:tA} Global:.PARSEDIR = /usr/src-topo/share/mk Global:.PARSEFILE = bsd.kmod.mk Result[] of :U is "/usr/src/sys" Applying[] :t to "/usr/src/sys" Result[] of :t is "/usr/src/sys" Result[] of :U is "/usr/src/sys" Applying[] :t to "/usr/src/sys" Result[] of :t is "/usr/src/sys" Result[] of :U is "/usr/src/sys" Applying[] :t to "/usr/src/sys" Result[] of :t is "/usr/src/sys" Global:.MAKE.MAKEFILES = /usr/src-topo/share/mk/sys.mk /usr/src-topo/share/mk/local.sys.env.mk /usr/src-topo/share/mk/src.sys.env.mk /usr/src-topo/share/mk/bsd.mkopt.m k /usr/src-topo/share/mk/src.sys.obj.mk /usr/src-topo/share/mk/auto.obj.mk /usr/src-topo/share/mk/bsd.suffixes.mk /usr/src-topo/share/mk/local.sys.mk /usr/src-topo/sha re/mk/src.sys.mk /usr/src-topo/sys/modules/vmm/Makefile /usr/src-topo/share/mk/bsd.kmod.mk /usr/src/sys/conf/kmod.mk ^ Thats gona bust something some day Global:.PARSEDIR = /usr/src/sys/conf Global:.PARSEFILE = kmod.mk Global:.INCLUDEDFROMDIR = /usr/src/sys/conf Oh my! Ug So something in bsd.kmod.mk is going very wrong... it looks like it starts to pull all sorts of stuff from /usr/src/sys! I seem to remember that there is code in the Makefiles that looks for the sys directory. I believe it can be directed to use a directory but in its absence it looks at some well known locations, which would probably fail if there is already a DIFFERENT tree in /usr/src. I have wrapped the long line so I can point to a difference between r329294 and r332262 make log of this file. r329294 make output: cc -O2 -pipe -DVMM_KEEP_STATS -DSMP -fno-strict-aliasing -Werror -D_KERNEL \ -DKLD_MODULE -nostdinc -I/usr/src-topo/sys/amd64/vmm \ -I/usr/src-topo/sys/amd64/vmm/io -I/usr/src-topo/sys/amd64/vmm/intel \ -I/usr/src-topo/sys/amd64/vmm/amd -I. -I/usr/src-topo/sys -fno-common \ ^ this is what I would expect ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Module compiles looking in /usr/src when alternate src tree is in use
On 4/12/2018 1:20 PM, Bryan Drewery wrote: > On 4/12/2018 1:11 PM, Bryan Drewery wrote: >> On 4/10/2018 5:29 PM, Rodney W. Grimes wrote: 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. You may find it helpful to do something like: make -dv -C sys/modules/vmm -V CFLAGS > /tmp/dvo 2>&1 egrep ':.PARSE|/usr/src/sys' /tmp/dvo | grep -B1 usr/src | more The arg to -V doesn't matter btw. You could narrow that down if you know what var -I/usr/src/sys is in (probably CFLAGS but you never know) the above should help find the makefile that is introducing the bogus -I >>> >>> Thank you, that does help narrow it down: (I backed up a vew lines >>> from the first place I saw src/.) >>> >>> ... >>> Global:.PARSEFILE = bsd.kmod.mk >>> Global:.PARSEDIR = /usr/src-topo/share/mk >>> Global:.PARSEFILE = bsd.kmod.mk >>> Result[] of :U is "/usr/src/sys" >>> Result[] of :U is "/usr/src/sys" >>> Global:SYSDIR = ${:U/usr/src/sys:tA} >>> Global:.PARSEDIR = /usr/src-topo/share/mk >>> Global:.PARSEFILE = bsd.kmod.mk >>> Result[] of :U is "/usr/src/sys" >>> Applying[] :t to "/usr/src/sys" >>> Result[] of :t is "/usr/src/sys" >>> Result[] of :U is "/usr/src/sys" >>> Applying[] :t to "/usr/src/sys" >>> Result[] of :t is "/usr/src/sys" >>> Result[] of :U is "/usr/src/sys" >>> Applying[] :t to "/usr/src/sys" >>> Result[] of :t is "/usr/src/sys" >>> Global:.MAKE.MAKEFILES = /usr/src-topo/share/mk/sys.mk >>> /usr/src-topo/share/mk/local.sys.env.mk >>> /usr/src-topo/share/mk/src.sys.env.mk /usr/src-topo/share/mk/bsd.mkopt.m >>> k /usr/src-topo/share/mk/src.sys.obj.mk /usr/src-topo/share/mk/auto.obj.mk >>> /usr/src-topo/share/mk/bsd.suffixes.mk /usr/src-topo/share/mk/local.sys.mk >>> /usr/src-topo/sha >>> re/mk/src.sys.mk /usr/src-topo/sys/modules/vmm/Makefile >>> /usr/src-topo/share/mk/bsd.kmod.mk /usr/src/sys/conf/kmod.mk >>> >>>^ >>> Thats gona bust something some day >>> >>> Global:.PARSEDIR = /usr/src/sys/conf >>> Global:.PARSEFILE = kmod.mk >>> Global:.INCLUDEDFROMDIR = /usr/src/sys/conf >>> Oh my! Ug >>> >>> >>> So something in bsd.kmod.mk is going very wrong... it looks like it >>> starts to pull all sorts of stuff from /usr/src/sys! >>> > > I have wrapped the long line so I can point to a difference between > r329294 and r332262 make log of this file. > > r329294 make output: > > cc -O2 -pipe -DVMM_KEEP_STATS -DSMP -fno-strict-aliasing -Werror > -D_KERNEL \ > -DKLD_MODULE -nostdinc -I/usr/src-topo/sys/amd64/vmm \ > -I/usr/src-topo/sys/amd64/vmm/io -I/usr/src-topo/sys/amd64/vmm/intel \ > -I/usr/src-topo/sys/amd64/vmm/amd -I. -I/usr/src-topo/sys -fno-common \ >^ this is what I > would expect >>> >> >> Is this buildkernel or a direct module directory build? >> >> Does reverting r331683 and r331682 help? Perhaps I missed ensuring >> SYSDIR is exported properly. >> > > Ok I see the problem with a direct module build. I am fixing it. Sorry > about that. > Fixed in r332453. -- Regards, Bryan Drewery signature.asc Description: OpenPGP digital signature
Re: Module compiles looking in /usr/src when alternate src tree is in use
On 4/12/2018 1:11 PM, Bryan Drewery wrote: > On 4/10/2018 5:29 PM, Rodney W. Grimes wrote: >>> 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. >>> >>> You may find it helpful to do something like: >>> >>> make -dv -C sys/modules/vmm -V CFLAGS > /tmp/dvo 2>&1 >>> egrep ':.PARSE|/usr/src/sys' /tmp/dvo | grep -B1 usr/src | more >>> >>> The arg to -V doesn't matter btw. >>> You could narrow that down if you know what var -I/usr/src/sys is in >>> (probably CFLAGS but you never know) >>> the above should help find the makefile that is introducing the bogus -I >>> >> >> Thank you, that does help narrow it down: (I backed up a vew lines >> from the first place I saw src/.) >> >> ... >> Global:.PARSEFILE = bsd.kmod.mk >> Global:.PARSEDIR = /usr/src-topo/share/mk >> Global:.PARSEFILE = bsd.kmod.mk >> Result[] of :U is "/usr/src/sys" >> Result[] of :U is "/usr/src/sys" >> Global:SYSDIR = ${:U/usr/src/sys:tA} >> Global:.PARSEDIR = /usr/src-topo/share/mk >> Global:.PARSEFILE = bsd.kmod.mk >> Result[] of :U is "/usr/src/sys" >> Applying[] :t to "/usr/src/sys" >> Result[] of :t is "/usr/src/sys" >> Result[] of :U is "/usr/src/sys" >> Applying[] :t to "/usr/src/sys" >> Result[] of :t is "/usr/src/sys" >> Result[] of :U is "/usr/src/sys" >> Applying[] :t to "/usr/src/sys" >> Result[] of :t is "/usr/src/sys" >> Global:.MAKE.MAKEFILES = /usr/src-topo/share/mk/sys.mk >> /usr/src-topo/share/mk/local.sys.env.mk >> /usr/src-topo/share/mk/src.sys.env.mk /usr/src-topo/share/mk/bsd.mkopt.m >> k /usr/src-topo/share/mk/src.sys.obj.mk /usr/src-topo/share/mk/auto.obj.mk >> /usr/src-topo/share/mk/bsd.suffixes.mk /usr/src-topo/share/mk/local.sys.mk >> /usr/src-topo/sha >> re/mk/src.sys.mk /usr/src-topo/sys/modules/vmm/Makefile >> /usr/src-topo/share/mk/bsd.kmod.mk /usr/src/sys/conf/kmod.mk >> >> ^ >> Thats gona bust something some day >> >> Global:.PARSEDIR = /usr/src/sys/conf >> Global:.PARSEFILE = kmod.mk >> Global:.INCLUDEDFROMDIR = /usr/src/sys/conf >> Oh my! Ug >> >> >> So something in bsd.kmod.mk is going very wrong... it looks like it >> starts to pull all sorts of stuff from /usr/src/sys! >> I have wrapped the long line so I can point to a difference between r329294 and r332262 make log of this file. r329294 make output: cc -O2 -pipe -DVMM_KEEP_STATS -DSMP -fno-strict-aliasing -Werror -D_KERNEL \ -DKLD_MODULE -nostdinc -I/usr/src-topo/sys/amd64/vmm \ -I/usr/src-topo/sys/amd64/vmm/io -I/usr/src-topo/sys/amd64/vmm/intel \ -I/usr/src-topo/sys/amd64/vmm/amd -I. -I/usr/src-topo/sys -fno-common \ ^ this is what I would expect >>> >>> >> > > Is this buildkernel or a direct module directory build? > > Does reverting r331683 and r331682 help? Perhaps I missed ensuring > SYSDIR is exported properly. > Ok I see the problem with a direct module build. I am fixing it. Sorry about that. -- Regards, Bryan Drewery signature.asc Description: OpenPGP digital signature
Re: Module compiles looking in /usr/src when alternate src tree is in use
On 4/10/2018 5:29 PM, Rodney W. Grimes wrote: >> 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. >> >> You may find it helpful to do something like: >> >> make -dv -C sys/modules/vmm -V CFLAGS > /tmp/dvo 2>&1 >> egrep ':.PARSE|/usr/src/sys' /tmp/dvo | grep -B1 usr/src | more >> >> The arg to -V doesn't matter btw. >> You could narrow that down if you know what var -I/usr/src/sys is in >> (probably CFLAGS but you never know) >> the above should help find the makefile that is introducing the bogus -I >> > > Thank you, that does help narrow it down: (I backed up a vew lines > from the first place I saw src/.) > > ... > Global:.PARSEFILE = bsd.kmod.mk > Global:.PARSEDIR = /usr/src-topo/share/mk > Global:.PARSEFILE = bsd.kmod.mk > Result[] of :U is "/usr/src/sys" > Result[] of :U is "/usr/src/sys" > Global:SYSDIR = ${:U/usr/src/sys:tA} > Global:.PARSEDIR = /usr/src-topo/share/mk > Global:.PARSEFILE = bsd.kmod.mk > Result[] of :U is "/usr/src/sys" > Applying[] :t to "/usr/src/sys" > Result[] of :t is "/usr/src/sys" > Result[] of :U is "/usr/src/sys" > Applying[] :t to "/usr/src/sys" > Result[] of :t is "/usr/src/sys" > Result[] of :U is "/usr/src/sys" > Applying[] :t to "/usr/src/sys" > Result[] of :t is "/usr/src/sys" > Global:.MAKE.MAKEFILES = /usr/src-topo/share/mk/sys.mk > /usr/src-topo/share/mk/local.sys.env.mk /usr/src-topo/share/mk/src.sys.env.mk > /usr/src-topo/share/mk/bsd.mkopt.m > k /usr/src-topo/share/mk/src.sys.obj.mk /usr/src-topo/share/mk/auto.obj.mk > /usr/src-topo/share/mk/bsd.suffixes.mk /usr/src-topo/share/mk/local.sys.mk > /usr/src-topo/sha > re/mk/src.sys.mk /usr/src-topo/sys/modules/vmm/Makefile > /usr/src-topo/share/mk/bsd.kmod.mk /usr/src/sys/conf/kmod.mk > > ^ > Thats gona bust something some day > > Global:.PARSEDIR = /usr/src/sys/conf > Global:.PARSEFILE = kmod.mk > Global:.INCLUDEDFROMDIR = /usr/src/sys/conf > Oh my! Ug > > > So something in bsd.kmod.mk is going very wrong... it looks like it > starts to pull all sorts of stuff from /usr/src/sys! > >>> >>> I have wrapped the long line so I can point to a difference between >>> r329294 and r332262 make log of this file. >>> >>> r329294 make output: >>> >>> cc -O2 -pipe -DVMM_KEEP_STATS -DSMP -fno-strict-aliasing -Werror >>> -D_KERNEL \ >>> -DKLD_MODULE -nostdinc -I/usr/src-topo/sys/amd64/vmm \ >>> -I/usr/src-topo/sys/amd64/vmm/io -I/usr/src-topo/sys/amd64/vmm/intel \ >>> -I/usr/src-topo/sys/amd64/vmm/amd -I. -I/usr/src-topo/sys -fno-common \ >>>^ this is what I >>> would expect >> >> > Is this buildkernel or a direct module directory build? Does reverting r331683 and r331682 help? Perhaps I missed ensuring SYSDIR is exported properly. -- Regards, Bryan Drewery signature.asc Description: OpenPGP digital signature
Re: Module compiles looking in /usr/src when alternate src tree is in use
Rodney W. Grimes wrote: > Thank you, that does help narrow it down: (I backed up a vew lines > from the first place I saw src/.) > > ... > Global:.PARSEFILE = bsd.kmod.mk > Global:.PARSEDIR = /usr/src-topo/share/mk > Global:.PARSEFILE = bsd.kmod.mk > Result[] of :U is "/usr/src/sys" > Result[] of :U is "/usr/src/sys" > Global:SYSDIR = ${:U/usr/src/sys:tA} That's from the .for loop in bsd.kmod.mk which is clearly inadequate. Since the tree for some time now, reliably sets SRCTOP that list should start with ${SRCTOP}/sys or ${SRCTOP:Uno}/sys just to be sure you ignore it if somehow unset. > So something in bsd.kmod.mk is going very wrong... it looks like it > starts to pull all sorts of stuff from /usr/src/sys! ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Module compiles looking in /usr/src when alternate src tree is in use
> 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. > > You may find it helpful to do something like: > > make -dv -C sys/modules/vmm -V CFLAGS > /tmp/dvo 2>&1 > egrep ':.PARSE|/usr/src/sys' /tmp/dvo | grep -B1 usr/src | more > > The arg to -V doesn't matter btw. > You could narrow that down if you know what var -I/usr/src/sys is in > (probably CFLAGS but you never know) > the above should help find the makefile that is introducing the bogus -I > Thank you, that does help narrow it down: (I backed up a vew lines from the first place I saw src/.) ... Global:.PARSEFILE = bsd.kmod.mk Global:.PARSEDIR = /usr/src-topo/share/mk Global:.PARSEFILE = bsd.kmod.mk Result[] of :U is "/usr/src/sys" Result[] of :U is "/usr/src/sys" Global:SYSDIR = ${:U/usr/src/sys:tA} Global:.PARSEDIR = /usr/src-topo/share/mk Global:.PARSEFILE = bsd.kmod.mk Result[] of :U is "/usr/src/sys" Applying[] :t to "/usr/src/sys" Result[] of :t is "/usr/src/sys" Result[] of :U is "/usr/src/sys" Applying[] :t to "/usr/src/sys" Result[] of :t is "/usr/src/sys" Result[] of :U is "/usr/src/sys" Applying[] :t to "/usr/src/sys" Result[] of :t is "/usr/src/sys" Global:.MAKE.MAKEFILES = /usr/src-topo/share/mk/sys.mk /usr/src-topo/share/mk/local.sys.env.mk /usr/src-topo/share/mk/src.sys.env.mk /usr/src-topo/share/mk/bsd.mkopt.m k /usr/src-topo/share/mk/src.sys.obj.mk /usr/src-topo/share/mk/auto.obj.mk /usr/src-topo/share/mk/bsd.suffixes.mk /usr/src-topo/share/mk/local.sys.mk /usr/src-topo/sha re/mk/src.sys.mk /usr/src-topo/sys/modules/vmm/Makefile /usr/src-topo/share/mk/bsd.kmod.mk /usr/src/sys/conf/kmod.mk ^ Thats gona bust something some day Global:.PARSEDIR = /usr/src/sys/conf Global:.PARSEFILE = kmod.mk Global:.INCLUDEDFROMDIR = /usr/src/sys/conf Oh my! Ug So something in bsd.kmod.mk is going very wrong... it looks like it starts to pull all sorts of stuff from /usr/src/sys! > > > > I have wrapped the long line so I can point to a difference between > > r329294 and r332262 make log of this file. > > > > r329294 make output: > > > > cc -O2 -pipe -DVMM_KEEP_STATS -DSMP -fno-strict-aliasing -Werror > > -D_KERNEL \ > > -DKLD_MODULE -nostdinc -I/usr/src-topo/sys/amd64/vmm \ > > -I/usr/src-topo/sys/amd64/vmm/io -I/usr/src-topo/sys/amd64/vmm/intel \ > > -I/usr/src-topo/sys/amd64/vmm/amd -I. -I/usr/src-topo/sys -fno-common \ > >^ this is what I > > would expect > > -- Rod Grimes rgri...@freebsd.org ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Module compiles looking in /usr/src when alternate src tree is in use
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. You may find it helpful to do something like: make -dv -C sys/modules/vmm -V CFLAGS > /tmp/dvo 2>&1 egrep ':.PARSE|/usr/src/sys' /tmp/dvo | grep -B1 usr/src | more The arg to -V doesn't matter btw. You could narrow that down if you know what var -I/usr/src/sys is in (probably CFLAGS but you never know) the above should help find the makefile that is introducing the bogus -I > > > I have wrapped the long line so I can point to a difference between > r329294 and r332262 make log of this file. > > r329294 make output: > > cc -O2 -pipe -DVMM_KEEP_STATS -DSMP -fno-strict-aliasing -Werror -D_KERNEL \ > -DKLD_MODULE -nostdinc -I/usr/src-topo/sys/amd64/vmm \ > -I/usr/src-topo/sys/amd64/vmm/io -I/usr/src-topo/sys/amd64/vmm/intel \ > -I/usr/src-topo/sys/amd64/vmm/amd -I. -I/usr/src-topo/sys -fno-common \ >^ this is what I would > expect ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Module compiles looking in /usr/src when alternate src tree is in use [actually the arm_neon.h and stdint.h issue]
On Mon, Apr 09, 2018 at 06:04:24AM -0700, Mark Millard wrote: > On 2018-Apr-8, at 10:08 PM, bob prohaska wrote: > >> . . . > > On my RPi3 > > root@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. > > > > > >> . . . > > > > 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. > > > > Looks like you copied the file there. Its presence is not a > build problem. See below. > > >From Feb 16 Email from you: > > From: bob prohaska > Subject: Re: RPI3 can't build kernel-toolchain > Date: February 16, 2018 at 9:09:27 AM PST > To: Mark Millard > Cc: freebsd-arm at freebsd.org, bob prohaska > . . . > Running > cp ./contrib/llvm/tools/clang/lib/Headers/stdint.h > /usr/lib/clang/6.0.0/include > didn't solve the problem. > I remembered the experiment that worked, and forgot the one that didn't. Thank you! bob prohaska ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Module compiles looking in /usr/src when alternate src tree is in use [actually the arm_neon.h and stdint.h issue]
On 2018-Apr-8, at 10:08 PM, bob prohaska wrote: >> . . . > On my RPi3 > root@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. > > >> . . . > > 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. > Looks like you copied the file there. Its presence is not a build problem. See below. >From Feb 16 Email from you: From: bob prohaska Subject: Re: RPI3 can't build kernel-toolchain Date: February 16, 2018 at 9:09:27 AM PST To: Mark Millard Cc: freebsd-arm at freebsd.org, bob prohaska . . . Running cp ./contrib/llvm/tools/clang/lib/Headers/stdint.h /usr/lib/clang/6.0.0/include didn't solve the problem. Using cp /usr/lib/include/stdint.h /usr/obj/usr/src/arm64.aarch64/tmp/usr/include/ does seem to be working. Since this is a self-hosted compile there's hope the resulting kernel will be more stable than r328935. . . . === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Module compiles looking in /usr/src when alternate src tree is in use [actually the arm_neon.h and stdint.h issue]
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 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 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?] 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. === Mark Millard marklmi26-fbsd at yahoo.com ( dsl-only.net went away in early 2018-Mar) ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
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 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 > > 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@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 ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
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 rgri...@freebsd.org ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
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". The line leading up to the error message is: --- 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/s ys -fno-common -g -fPIC -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? > > 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. Thanks for reading, bob prohaska ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Module compiles looking in /usr/src when alternate src tree is in use
> 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? 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/. > 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. In my case I was able to proove it out as my compile from /usr/src-topo worked just fine after I copied my 3 modified header files to /usr/src. -- Rod Grimes rgri...@freebsd.org ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Module compiles looking in /usr/src when alternate src tree is in use
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? If the two problems are related, should the subject line on the bug report be changed? Thanks for reading, bob prohaska ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Module compiles looking in /usr/src when alternate src tree is in use
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. I have wrapped the long line so I can point to a difference between r329294 and r332262 make log of this file. r329294 make output: cc -O2 -pipe -DVMM_KEEP_STATS -DSMP -fno-strict-aliasing -Werror -D_KERNEL \ -DKLD_MODULE -nostdinc -I/usr/src-topo/sys/amd64/vmm \ -I/usr/src-topo/sys/amd64/vmm/io -I/usr/src-topo/sys/amd64/vmm/intel \ -I/usr/src-topo/sys/amd64/vmm/amd -I. -I/usr/src-topo/sys -fno-common \ ^ this is what I would expect -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -MD \ -MF .depend.vmm.o -MTvmm.o -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse \ -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fwrapv \ -fstack-protector -Wall -Wredundant-decls -Wnested-externs \ -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual \ -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ \ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas \ -Wno-error-tautological-compare -Wno-error-empty-body \ -Wno-error-parentheses-equality -Wno-error-unused-function \ -Wno-error-pointer-sign -Wno-error-shift-negative-value \ -Wno-error-address-of-packed-member -mno-aes -mno-avx -std=iso9899:1999 -c /usr/src-topo/sys/amd64/vmm/vmm.c -o vmm.o No error, and I get my vmm.ko! r332262 make output: cc -O2 -pipe -DVMM_KEEP_STATS -DSMP -fno-strict-aliasing -Werror -D_KERNEL \ -DKLD_MODULE -nostdinc -I/usr/src-topo/sys/amd64/vmm \ -I/usr/src-topo/sys/amd64/vmm/io -I/usr/src-topo/sys/amd64/vmm/intel \ -I/usr/src-topo/sys/amd64/vmm/amd -I. -I/usr/src/sys -fno-common \ why HERE? -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -MD \ -MF.depend.vmm.o -MTvmm.o -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse \ -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fwrapv \ -fstack-protector -Wall -Wredundant-decls -Wnested-externs \ -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual \ -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ \ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas \ -Wno-error-tautological-compare -Wno-error-empty-body \ -Wno-error-parentheses-equality -Wno-error-unused-function \ -Wno-error-pointer-sign -Wno-error-shift-negative-value \ -Wno-error-address-of-packed-member -mno-aes -mno-avx -std=iso9899:1999 \ -c /usr/src-topo/sys/amd64/vmm/vmm.c -o vmm.o /usr/src-topo/sys/amd64/vmm/vmm.c:476:1: error: no previous prototype for function 'vm_get_topology' [-Werror,-Wmissing-prototypes] vm_get_topology(struct vm *vm, uint16_t *sockets, uint16_t *cores, ^ /usr/src-topo/sys/amd64/vmm/vmm.c:486:1: error: no previous prototype for function 'vm_set_topology' [-Werror,-Wmissing-prototypes] vm_set_topology(struct vm *vm, uint16_t sockets, uint16_t cores, ^ 2 errors generated. *** Error code 1 Stop. make: stopped in /usr/src-topo/sys/modules/vmm UGLY GROSS HACK TO FIX: cp /usr/src-topo/amd64/include/vmm.h /usr/src/sys/amd64/include/vmm.h Regards, -- Rod Grimes rgri...@freebsd.org ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"