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

[Julian Elischer]

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

[Bryan Drewery]

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

[Bryan Drewery]

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

[Bryan Drewery]

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

[Simon J. Gerraty]

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]

> 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

[Simon J. Gerraty]

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]

[bob prohaska]

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]

[Mark Millard]

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]

[Mark Millard]

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]

[bob prohaska]

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

[Rodney W. Grimes]

> 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

[bob prohaska]

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

[Rodney W. Grimes]

> 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

[bob prohaska]

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"