Re: svn commit: r297435 - head: still problems for stage 3 when gcc 4.2.1 is avoided (powerpc64 self-hosted build)

2016-03-31 Thread Mark Millard 
On 2016-Mar-31, at 8:14 PM, Mark Millard  wrote:
> 
> On 2016-Mar-31, at 5:02 PM, Bryan Drewery  wrote:
> 
>> This should be fine with my fix too.
>> 
>> Trying add this to your make.conf for now:
>> 
>> CFLAGS.gcc+= -isystem /usr/include
> 
> [Context note: I normally use:
> 
>> WITHOUT_CROSS_COMPILER=
>> #
>> WITH_FAST_DEPEND=
>> WITH_LIBCPLUSPLUS=
>> WITH_BOOT=
>> WITH_CLANG=
>> WITH_CLANG_IS_CC=
>> WITH_CLANG_FULL=
>> WITH_LLDB=
> 
> 
> so clang is built by powerpc64-gcc's tools even though clang is not used for 
> the build.
> ]
> 
> The result was almost immediate build failure:
> 
>> --- _bootstrap-tools-lib/clang/libllvmsupport ---
>> --- APFloat.o ---
>> In file included from 
>> /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/include/llvm/Support/AlignOf.h:19:0,
>> from 
>> /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/include/llvm/ADT/SmallVector.h:18,
>> from 
>> /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/include/llvm/Support/Allocator.h:24,
>> from 
>> /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/include/llvm/ADT/StringMap.h:18,
>> from 
>> /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/include/llvm/Support/Host.h:17,
>> from 
>> /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/include/llvm/ADT/Hashing.h:49,
>> from 
>> /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/include/llvm/ADT/ArrayRef.h:13,
>> from 
>> /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/include/llvm/ADT/APInt.h:19,
>> from 
>> /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/include/llvm/ADT/APFloat.h:20,
>> from 
>> /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/APFloat.cpp:15:
>> /usr/local/lib/gcc49/include/c++/cstddef:51:11: error: '::max_align_t' has 
>> not been declared
>>   using ::max_align_t;
>   ^
> 
> ===
> Mark Millard
> markmi at dsl-only.net

I added using -v in CFLAGS.gcc in order for it to report include search paths. 
The last one of reported in the script output looks like:

> ignoring nonexistent directory 
> "/usr/local/lib/gcc49/gcc/powerpc64-portbld-freebsd11.0/4.9.4/../../../../../powerpc64-portbld-freebsd11.0/include"
> ignoring duplicate directory "/usr/include"
> #include "..." search starts here:
> #include <...> search starts here:
>  /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/include
>  /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/tools/clang/include
>  /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support
>  .
>  
> /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/../../lib/clang/include
>  /usr/obj/xtoolchain/powerpc.powerpc64/usr/src/tmp/legacy/usr/include
>  /usr/include
>  /usr/local/lib/gcc49/include/c++/
>  /usr/local/lib/gcc49/include/c++//powerpc64-portbld-freebsd11.0
>  /usr/local/lib/gcc49/include/c++//backward
>  /usr/local/lib/gcc49/gcc/powerpc64-portbld-freebsd11.0/4.9.4/include
>  /usr/local/include
>  /usr/local/lib/gcc49/gcc/powerpc64-portbld-freebsd11.0/4.9.4/include-fixed
> End of search list.

I appears that C++ needs its own override for where to find C++ header before 
looking in the gcc49 specific places.

These sorts of odd, hard to avoid dependencies are part of why I asked if there 
was a standard/recommend assignment to use for CC/XCC: I was hoping there was a 
known-good way to compile that avoided the issues, possibly by using 
powerpc64-gcc tools for CC/XCC as well.

FYI: The last C compile in this script output lists:

> ignoring nonexistent directory 
> "/usr/local/lib/gcc49/gcc/powerpc64-portbld-freebsd11.0/4.9.4/../../../../../powerpc64-portbld-freebsd11.0/include"
> ignoring duplicate directory "/usr/include"
> ignoring duplicate directory 
> "/usr/src/kerberos5/tools/make-roken/../../include"
> #include "..." search starts here:
> #include <...> search starts here:
>  /usr/src/kerberos5/tools/make-roken/../../include
>  /usr/obj/xtoolchain/powerpc.powerpc64/usr/src/tmp/legacy/usr/include
>  /usr/include
>  /usr/local/lib/gcc49/gcc/powerpc64-portbld-freebsd11.0/4.9.4/include
>  /usr/local/include
>  /usr/local/lib/gcc49/gcc/powerpc64-portbld-freebsd11.0/4.9.4/include-fixed
> End of search list.


===
Mark Millard
markmi at dsl-only.net


On 2016-Mar-31, at 5:02 PM, Bryan Drewery  wrote:

> On 3/31/16 4:42 PM, Mark Millard wrote:
>> On 2016-Mar-31, at 3:34 PM, Bryan Drewery  wrote:
 #include "..." search starts here:
 #include <...> search starts here:
 /usr/local/lib/gcc49/include/c++/
 /usr/local/lib/gcc49/include/c++//x86_64-portbld-freebsd11.0
 /usr/local/lib/gcc49/include/c++//backward
 /usr/local/lib/gcc49/gcc/x86_64-portbld-freebsd11.0/4.9.4/include
 /usr/local/include
 /usr/local/lib/gcc49/gcc/x86_64-portbld-freebsd11.0/4.9.4/include-fixed
 /usr/include
 End of search list.
>> Beyond /usr/local/include is also the fun

Re: svn commit: r297435 - head: still problems for stage 3 when gcc 4.2.1 is avoided (powerpc64 self-hosted build)

2016-03-31 Thread Mark Millard 
On 2016-Mar-31, at 5:02 PM, Bryan Drewery  wrote:

> This should be fine with my fix too.
> 
> Trying add this to your make.conf for now:
> 
> CFLAGS.gcc+= -isystem /usr/include

[Context note: I normally use:

> WITHOUT_CROSS_COMPILER=
> #
> WITH_FAST_DEPEND=
> WITH_LIBCPLUSPLUS=
> WITH_BOOT=
> WITH_CLANG=
> WITH_CLANG_IS_CC=
> WITH_CLANG_FULL=
> WITH_LLDB=


so clang is built by powerpc64-gcc's tools even though clang is not used for 
the build.
]

The result was almost immediate build failure:

> --- _bootstrap-tools-lib/clang/libllvmsupport ---
> --- APFloat.o ---
> In file included from 
> /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/include/llvm/Support/AlignOf.h:19:0,
>  from 
> /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/include/llvm/ADT/SmallVector.h:18,
>  from 
> /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/include/llvm/Support/Allocator.h:24,
>  from 
> /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/include/llvm/ADT/StringMap.h:18,
>  from 
> /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/include/llvm/Support/Host.h:17,
>  from 
> /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/include/llvm/ADT/Hashing.h:49,
>  from 
> /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/include/llvm/ADT/ArrayRef.h:13,
>  from 
> /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/include/llvm/ADT/APInt.h:19,
>  from 
> /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/include/llvm/ADT/APFloat.h:20,
>  from 
> /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/APFloat.cpp:15:
> /usr/local/lib/gcc49/include/c++/cstddef:51:11: error: '::max_align_t' has 
> not been declared
>using ::max_align_t;
   ^

===
Mark Millard
markmi at dsl-only.net

On 2016-Mar-31, at 5:02 PM, Bryan Drewery  wrote:

> On 3/31/16 4:42 PM, Mark Millard wrote:
>> On 2016-Mar-31, at 3:34 PM, Bryan Drewery  wrote:
 #include "..." search starts here:
 #include <...> search starts here:
 /usr/local/lib/gcc49/include/c++/
 /usr/local/lib/gcc49/include/c++//x86_64-portbld-freebsd11.0
 /usr/local/lib/gcc49/include/c++//backward
 /usr/local/lib/gcc49/gcc/x86_64-portbld-freebsd11.0/4.9.4/include
 /usr/local/include
 /usr/local/lib/gcc49/gcc/x86_64-portbld-freebsd11.0/4.9.4/include-fixed
 /usr/include
 End of search list.
>> Beyond /usr/local/include is also the fun of [ignoring C++ specific issues]:
>> (My quoting of a copy/paste)
>> 
 # ls /usr/local/lib/gcc49/gcc/powerpc64-portbld-freebsd11.0/4.9.4/include*
 /usr/local/lib/gcc49/gcc/powerpc64-portbld-freebsd11.0/4.9.4/include:
 altivec.h  iso646.hppc-asm.h   
 spu2vmx.h   stdatomic.h stdint-gcc.h
 unwind.h
 float.hobjcppu_intrinsics.h
 ssp stdbool.h   stdint.h
 varargs.h
 htmintrin.homp.h   si2vmx.h
 stdalign.h  stddef.hstdnoreturn.h   
 vec_types.h
 htmxlintrin.h  paired.hspe.h   
 stdarg.hstdfix.htgmath.h
 
 /usr/local/lib/gcc49/gcc/powerpc64-portbld-freebsd11.0/4.9.4/include-fixed:
 README libmilter   limits.hnetinet 
 stddef.hstdio.h stdlib.hsys 
 syslimits.h unistd.hwchar.h
>> But at least in recent times after WCHAR_TYPE was fixed for 
>> powerpc/powerpc64 I've not had troubles that traced to these for CC and CXX 
>> being based on gcc49 while XCC and XCXX were based on powerpc64-gcc for 
>> buildworld/buildkernel on a powerpc64 host.
>> 
>> I have had various examples of /usr/local/include/ files breaking builds 
>> depending on what ports were in place at the time. All along I've been doing 
>> renaming in that area to allow buildworld/buildkernel use.
> 
> This should be fine with my fix too.
> 
> Trying add this to your make.conf for now:
> 
> CFLAGS.gcc+= -isystem /usr/include
> 
-- 
Regards,
Bryan Drewery

___
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: svn commit: r297435 - head: still problems for stage 3 when gcc 4.2.1 is avoided (powerpc64 self-hosted build)

2016-03-31 Thread Mark Millard 
On 2016-Mar-31, at 5:02 PM, Bryan Drewery  wrote:

> This should be fine with my fix too.
> 
> Trying add this to your make.conf for now:
> 
> CFLAGS.gcc+= -isystem /usr/include

I'll try that. But just FYI: here are the lists of files from gcc49 that having 
/usr/include first will change what gcc49 sets up for itself and has been using 
in my past activities (spanning both 4.9.4/include/ and 4.9.4/include-fixed/ ):

> # diff -rq /usr/include/ 
> /usr/local/lib/gcc49/gcc/powerpc64-portbld-freebsd11.0/4.9.4/include/ | grep 
> "^Files "
> Files /usr/include/float.h and 
> /usr/local/lib/gcc49/gcc/powerpc64-portbld-freebsd11.0/4.9.4/include/float.h 
> differ
> Files /usr/include/iso646.h and 
> /usr/local/lib/gcc49/gcc/powerpc64-portbld-freebsd11.0/4.9.4/include/iso646.h 
> differ
> Files /usr/include/ssp/ssp.h and 
> /usr/local/lib/gcc49/gcc/powerpc64-portbld-freebsd11.0/4.9.4/include/ssp/ssp.h
>  differ
> Files /usr/include/ssp/stdio.h and 
> /usr/local/lib/gcc49/gcc/powerpc64-portbld-freebsd11.0/4.9.4/include/ssp/stdio.h
>  differ
> Files /usr/include/ssp/string.h and 
> /usr/local/lib/gcc49/gcc/powerpc64-portbld-freebsd11.0/4.9.4/include/ssp/string.h
>  differ
> Files /usr/include/ssp/unistd.h and 
> /usr/local/lib/gcc49/gcc/powerpc64-portbld-freebsd11.0/4.9.4/include/ssp/unistd.h
>  differ
> Files /usr/include/stdalign.h and 
> /usr/local/lib/gcc49/gcc/powerpc64-portbld-freebsd11.0/4.9.4/include/stdalign.h
>  differ
> Files /usr/include/stdarg.h and 
> /usr/local/lib/gcc49/gcc/powerpc64-portbld-freebsd11.0/4.9.4/include/stdarg.h 
> differ
> Files /usr/include/stdatomic.h and 
> /usr/local/lib/gcc49/gcc/powerpc64-portbld-freebsd11.0/4.9.4/include/stdatomic.h
>  differ
> Files /usr/include/stdbool.h and 
> /usr/local/lib/gcc49/gcc/powerpc64-portbld-freebsd11.0/4.9.4/include/stdbool.h
>  differ
> Files /usr/include/stddef.h and 
> /usr/local/lib/gcc49/gcc/powerpc64-portbld-freebsd11.0/4.9.4/include/stddef.h 
> differ
> Files /usr/include/stdint.h and 
> /usr/local/lib/gcc49/gcc/powerpc64-portbld-freebsd11.0/4.9.4/include/stdint.h 
> differ
> Files /usr/include/stdnoreturn.h and 
> /usr/local/lib/gcc49/gcc/powerpc64-portbld-freebsd11.0/4.9.4/include/stdnoreturn.h
>  differ
> Files /usr/include/tgmath.h and 
> /usr/local/lib/gcc49/gcc/powerpc64-portbld-freebsd11.0/4.9.4/include/tgmath.h 
> differ
> Files /usr/include/varargs.h and 
> /usr/local/lib/gcc49/gcc/powerpc64-portbld-freebsd11.0/4.9.4/include/varargs.h
>  differ

> # diff -rq /usr/include/ 
> /usr/local/lib/gcc49/gcc/powerpc64-portbld-freebsd11.0/4.9.4/include-fixed/ | 
> grep "^Files "
> Files /usr/include/libmilter/mfapi.h and 
> /usr/local/lib/gcc49/gcc/powerpc64-portbld-freebsd11.0/4.9.4/include-fixed/libmilter/mfapi.h
>  differ
> Files /usr/include/limits.h and 
> /usr/local/lib/gcc49/gcc/powerpc64-portbld-freebsd11.0/4.9.4/include-fixed/limits.h
>  differ
> Files /usr/include/netinet/ip_fil.h and 
> /usr/local/lib/gcc49/gcc/powerpc64-portbld-freebsd11.0/4.9.4/include-fixed/netinet/ip_fil.h
>  differ
> Files /usr/include/netinet/ip_lookup.h and 
> /usr/local/lib/gcc49/gcc/powerpc64-portbld-freebsd11.0/4.9.4/include-fixed/netinet/ip_lookup.h
>  differ
> Files /usr/include/netinet/ip_nat.h and 
> /usr/local/lib/gcc49/gcc/powerpc64-portbld-freebsd11.0/4.9.4/include-fixed/netinet/ip_nat.h
>  differ
> Files /usr/include/netinet/ip_proxy.h and 
> /usr/local/lib/gcc49/gcc/powerpc64-portbld-freebsd11.0/4.9.4/include-fixed/netinet/ip_proxy.h
>  differ
> Files /usr/include/netinet/ip_scan.h and 
> /usr/local/lib/gcc49/gcc/powerpc64-portbld-freebsd11.0/4.9.4/include-fixed/netinet/ip_scan.h
>  differ
> Files /usr/include/netinet/ip_state.h and 
> /usr/local/lib/gcc49/gcc/powerpc64-portbld-freebsd11.0/4.9.4/include-fixed/netinet/ip_state.h
>  differ
> Files /usr/include/stddef.h and 
> /usr/local/lib/gcc49/gcc/powerpc64-portbld-freebsd11.0/4.9.4/include-fixed/stddef.h
>  differ
> Files /usr/include/stdio.h and 
> /usr/local/lib/gcc49/gcc/powerpc64-portbld-freebsd11.0/4.9.4/include-fixed/stdio.h
>  differ
> Files /usr/include/stdlib.h and 
> /usr/local/lib/gcc49/gcc/powerpc64-portbld-freebsd11.0/4.9.4/include-fixed/stdlib.h
>  differ
> Files /usr/include/sys/types.h and 
> /usr/local/lib/gcc49/gcc/powerpc64-portbld-freebsd11.0/4.9.4/include-fixed/sys/types.h
>  differ
> Files /usr/include/unistd.h and 
> /usr/local/lib/gcc49/gcc/powerpc64-portbld-freebsd11.0/4.9.4/include-fixed/unistd.h
>  differ
> Files /usr/include/wchar.h and 
> /usr/local/lib/gcc49/gcc/powerpc64-portbld-freebsd11.0/4.9.4/include-fixed/wchar.h
>  differ

===
Mark Millard
mar...@dsl-only.net

On 2016-Mar-31, at 5:02 PM, Bryan Drewery  wrote:

On 3/31/16 4:42 PM, Mark Millard wrote:
> On 2016-Mar-31, at 3:34 PM, Bryan Drewery  wrote:
>>> #include "..." search starts here:
>>> #include <...> search starts here:
>>> /usr/local/lib/gcc49/include/c++/
>>> /usr/local/lib/gcc49/include/c++//x86_64-portbld-freebsd11.0
>>>

Re: svn commit: r297435 - head: still problems for stage 3 when gcc 4.2.1 is avoided (powerpc64 self-hosted build)

2016-03-31 Thread Bryan Drewery 
On 3/31/16 4:42 PM, Mark Millard wrote:
> On 2016-Mar-31, at 3:34 PM, Bryan Drewery  wrote:
>> > #include "..." search starts here:
>> > #include <...> search starts here:
>> > /usr/local/lib/gcc49/include/c++/
>> > /usr/local/lib/gcc49/include/c++//x86_64-portbld-freebsd11.0
>> > /usr/local/lib/gcc49/include/c++//backward
>> > /usr/local/lib/gcc49/gcc/x86_64-portbld-freebsd11.0/4.9.4/include
>> > /usr/local/include
>> > /usr/local/lib/gcc49/gcc/x86_64-portbld-freebsd11.0/4.9.4/include-fixed
>> > /usr/include
>> > End of search list.
> Beyond /usr/local/include is also the fun of [ignoring C++ specific issues]:
> (My quoting of a copy/paste)
> 
>> > # ls /usr/local/lib/gcc49/gcc/powerpc64-portbld-freebsd11.0/4.9.4/include*
>> > /usr/local/lib/gcc49/gcc/powerpc64-portbld-freebsd11.0/4.9.4/include:
>> > altivec.h  iso646.hppc-asm.h   
>> > spu2vmx.h   stdatomic.h stdint-gcc.h
>> > unwind.h
>> > float.hobjcppu_intrinsics.h
>> > ssp stdbool.h   stdint.h
>> > varargs.h
>> > htmintrin.homp.h   si2vmx.h
>> > stdalign.h  stddef.hstdnoreturn.h   
>> > vec_types.h
>> > htmxlintrin.h  paired.hspe.h   
>> > stdarg.hstdfix.htgmath.h
>> > 
>> > /usr/local/lib/gcc49/gcc/powerpc64-portbld-freebsd11.0/4.9.4/include-fixed:
>> > README libmilter   limits.hnetinet 
>> > stddef.hstdio.h stdlib.hsys 
>> > syslimits.h unistd.hwchar.h
> But at least in recent times after WCHAR_TYPE was fixed for powerpc/powerpc64 
> I've not had troubles that traced to these for CC and CXX being based on 
> gcc49 while XCC and XCXX were based on powerpc64-gcc for 
> buildworld/buildkernel on a powerpc64 host.
> 
> I have had various examples of /usr/local/include/ files breaking builds 
> depending on what ports were in place at the time. All along I've been doing 
> renaming in that area to allow buildworld/buildkernel use.

This should be fine with my fix too.

Trying add this to your make.conf for now:

CFLAGS.gcc+= -isystem /usr/include

-- 
Regards,
Bryan Drewery
___
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: svn commit: r297435 - head: still problems for stage 3 when gcc 4.2.1 is avoided (powerpc64 self-hosted build)

2016-03-31 Thread Mark Millard 
On 2016-Mar-31, at 3:34 PM, Bryan Drewery  wrote:
> #include "..." search starts here:
> #include <...> search starts here:
> /usr/local/lib/gcc49/include/c++/
> /usr/local/lib/gcc49/include/c++//x86_64-portbld-freebsd11.0
> /usr/local/lib/gcc49/include/c++//backward
> /usr/local/lib/gcc49/gcc/x86_64-portbld-freebsd11.0/4.9.4/include
> /usr/local/include
> /usr/local/lib/gcc49/gcc/x86_64-portbld-freebsd11.0/4.9.4/include-fixed
> /usr/include
> End of search list.

Beyond /usr/local/include is also the fun of [ignoring C++ specific issues]:
(My quoting of a copy/paste)

> # ls /usr/local/lib/gcc49/gcc/powerpc64-portbld-freebsd11.0/4.9.4/include*
> /usr/local/lib/gcc49/gcc/powerpc64-portbld-freebsd11.0/4.9.4/include:
> altivec.h iso646.hppc-asm.h   
> spu2vmx.h   stdatomic.h stdint-gcc.h
> unwind.h
> float.h   objcppu_intrinsics.h
> ssp stdbool.h   stdint.h
> varargs.h
> htmintrin.h   omp.h   si2vmx.h
> stdalign.h  stddef.hstdnoreturn.h   
> vec_types.h
> htmxlintrin.h paired.hspe.h   
> stdarg.hstdfix.htgmath.h
> 
> /usr/local/lib/gcc49/gcc/powerpc64-portbld-freebsd11.0/4.9.4/include-fixed:
> READMElibmilter   limits.hnetinet 
> stddef.hstdio.h stdlib.hsys syslimits.h   
>   unistd.hwchar.h

But at least in recent times after WCHAR_TYPE was fixed for powerpc/powerpc64 
I've not had troubles that traced to these for CC and CXX being based on gcc49 
while XCC and XCXX were based on powerpc64-gcc for buildworld/buildkernel on a 
powerpc64 host.

I have had various examples of /usr/local/include/ files breaking builds 
depending on what ports were in place at the time. All along I've been doing 
renaming in that area to allow buildworld/buildkernel use.

===
Mark Millard
markmi at dsl-only.net

Message history:

On 2016-Mar-31, at 3:34 PM, Bryan Drewery  wrote:
> 
> On 3/31/16 3:02 PM, Mark Millard wrote:
 We likely just need to prioritize /usr/include over /usr/local/include
 for these phases, which gcc49 may have backwards since it has its prefix
 set to /usr/local from the ports build.
> 
> Yup this is the problem with using the ports compiler as the "host"
> compiler:
> 
>> # echo '' |/usr/local/bin/gcc49 -v -x c++ - -o /dev/null
>> Using built-in specs.
>> COLLECT_GCC=/usr/local/bin/gcc49
>> COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc49/gcc/x86_64-portbld-freebsd11.0/4.9.4/lto-wrapper
>> Target: x86_64-portbld-freebsd11.0
>> Configured with: ./../gcc-4.9-20160210/configure 
>> --with-build-config=bootstrap-debug --disable-nls 
>> --enable-gnu-indirect-function --libdir=/usr/local/lib/gcc49 
>> --libexecdir=/usr/local/libexec/gcc49 --program-suffix=49 
>> --with-as=/usr/local/bin/as --with-gmp=/usr/local 
>> --with-gxx-include-dir=/usr/local/lib/gcc49/include/c++/ 
>> --with-ld=/usr/local/bin/ld --with-pkgversion='FreeBSD Ports Collection' 
>> --with-system-zlib --with-ecj-jar=/usr/local/share/java/ecj-4.5.jar 
>> --enable-languages=c,c++,objc,fortran,java --prefix=/usr/local 
>> --localstatedir=/var --mandir=/usr/local/man --infodir=/usr/local/info/gcc49 
>> --build=x86_64-portbld-freebsd11.0
>> Thread model: posix
>> gcc version 4.9.4 20160210 (prerelease) (FreeBSD Ports Collection)
>> COLLECT_GCC_OPTIONS='-v' '-o' '/dev/null' '-mtune=generic' '-march=x86-64'
>> /usr/local/libexec/gcc49/gcc/x86_64-portbld-freebsd11.0/4.9.4/cc1plus -quiet 
>> -v - -quiet -dumpbase - -mtune=generic -march=x86-64 -auxbase - -version -o 
>> /tmp//ccA75yFy.s
>> GNU C++ (FreeBSD Ports Collection) version 4.9.4 20160210 (prerelease) 
>> (x86_64-portbld-freebsd11.0)
>>compiled by GNU C version 4.9.4 20160210 (prerelease), GMP version 
>> 5.1.3, MPFR version 3.1.3, MPC version 1.0.3
>> GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
>> ignoring nonexistent directory 
>> "/usr/local/lib/gcc49/gcc/x86_64-portbld-freebsd11.0/4.9.4/../../../../../x86_64-portbld-freebsd11.0/include"
>> #include "..." search starts here:
>> #include <...> search starts here:
>> /usr/local/lib/gcc49/include/c++/
>> /usr/local/lib/gcc49/include/c++//x86_64-portbld-freebsd11.0
>> /usr/local/lib/gcc49/include/c++//backward
>> /usr/local/lib/gcc49/gcc/x86_64-portbld-freebsd11.0/4.9.4/include
>> /usr/local/include
>> /usr/local/lib/gcc49/gcc/x86_64-portbld-freebsd11.0/4.9.4/include-fixed
>> /usr/include
>> End of search list.
> 
> Note the /usr/local/include and /usr/include order near the end.
> 
> Passing -isystem /usr/include seems to fix it:
> 
>> # echo '' |/usr/local/bin/gcc49 -v -x c++ - -o /dev/null -isystem 
>> /usr/include
>> Using built-in specs.
>> COLLECT_GCC=/usr/local/bin/gcc49
>>

Re: svn commit: r297435 - head: still problems for stage 3 when gcc 4.2.1 is avoided (powerpc64 self-hosted build)

2016-03-31 Thread Warner Losh 

> On Mar 31, 2016, at 4:34 PM, Bryan Drewery  wrote:
> I didn't realize the ports compiler was defaulting /usr/local/include
> into the search path now.  It does not have /usr/local/lib in the
> default library path as far as I can tell.  It's also broken for its
> -rpath (noted in its pkg-message).  So having a default
> /usr/local/include path seems odd.

It has for a while now. It’s one of the maddening inconsistencies that abound 
in this
area. I took a poll a while ago and there seemed to be widespread support for 
adding
it to the base compiler.

> Adding -isystem /usr/include to fix this is probably possible but
> there's a risk someone will remove it as redundant.  In this case I wish
> /usr/include was first but I'm not sure what impact that would have on
> consumers expecting /usr/local/include (and /usr/local/lib) overrides to
> work, though they would need to pass a -L /usr/local/lib anyhow and
> would likely be passing -I /usr/local/lib too.

/usr/include should be first. But it isn’t. That’s another inconsistency that 
was found
when we looked at /usr/local stuff. Someone recently added /usr/local/bin to 
the path,
if I recall correctly.

Warner



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: svn commit: r297435 - head: still problems for stage 3 when gcc 4.2.1 is avoided (powerpc64 self-hosted build)

2016-03-31 Thread Bryan Drewery 
On 3/31/16 3:02 PM, Mark Millard wrote:
>> > We likely just need to prioritize /usr/include over /usr/local/include
>> > for these phases, which gcc49 may have backwards since it has its prefix
>> > set to /usr/local from the ports build.

Yup this is the problem with using the ports compiler as the "host"
compiler:

> # echo '' |/usr/local/bin/gcc49 -v -x c++ - -o /dev/null
> Using built-in specs.
> COLLECT_GCC=/usr/local/bin/gcc49
> COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc49/gcc/x86_64-portbld-freebsd11.0/4.9.4/lto-wrapper
> Target: x86_64-portbld-freebsd11.0
> Configured with: ./../gcc-4.9-20160210/configure 
> --with-build-config=bootstrap-debug --disable-nls 
> --enable-gnu-indirect-function --libdir=/usr/local/lib/gcc49 
> --libexecdir=/usr/local/libexec/gcc49 --program-suffix=49 
> --with-as=/usr/local/bin/as --with-gmp=/usr/local 
> --with-gxx-include-dir=/usr/local/lib/gcc49/include/c++/ 
> --with-ld=/usr/local/bin/ld --with-pkgversion='FreeBSD Ports Collection' 
> --with-system-zlib --with-ecj-jar=/usr/local/share/java/ecj-4.5.jar 
> --enable-languages=c,c++,objc,fortran,java --prefix=/usr/local 
> --localstatedir=/var --mandir=/usr/local/man --infodir=/usr/local/info/gcc49 
> --build=x86_64-portbld-freebsd11.0
> Thread model: posix
> gcc version 4.9.4 20160210 (prerelease) (FreeBSD Ports Collection)
> COLLECT_GCC_OPTIONS='-v' '-o' '/dev/null' '-mtune=generic' '-march=x86-64'
>  /usr/local/libexec/gcc49/gcc/x86_64-portbld-freebsd11.0/4.9.4/cc1plus -quiet 
> -v - -quiet -dumpbase - -mtune=generic -march=x86-64 -auxbase - -version -o 
> /tmp//ccA75yFy.s
> GNU C++ (FreeBSD Ports Collection) version 4.9.4 20160210 (prerelease) 
> (x86_64-portbld-freebsd11.0)
> compiled by GNU C version 4.9.4 20160210 (prerelease), GMP version 
> 5.1.3, MPFR version 3.1.3, MPC version 1.0.3
> GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
> ignoring nonexistent directory 
> "/usr/local/lib/gcc49/gcc/x86_64-portbld-freebsd11.0/4.9.4/../../../../../x86_64-portbld-freebsd11.0/include"
> #include "..." search starts here:
> #include <...> search starts here:
>  /usr/local/lib/gcc49/include/c++/
>  /usr/local/lib/gcc49/include/c++//x86_64-portbld-freebsd11.0
>  /usr/local/lib/gcc49/include/c++//backward
>  /usr/local/lib/gcc49/gcc/x86_64-portbld-freebsd11.0/4.9.4/include
>  /usr/local/include
>  /usr/local/lib/gcc49/gcc/x86_64-portbld-freebsd11.0/4.9.4/include-fixed
>  /usr/include
> End of search list.

Note the /usr/local/include and /usr/include order near the end.

Passing -isystem /usr/include seems to fix it:

> # echo '' |/usr/local/bin/gcc49 -v -x c++ - -o /dev/null -isystem /usr/include
> Using built-in specs.
> COLLECT_GCC=/usr/local/bin/gcc49
> COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc49/gcc/x86_64-portbld-freebsd11.0/4.9.4/lto-wrapper
> Target: x86_64-portbld-freebsd11.0
> Configured with: ./../gcc-4.9-20160210/configure 
> --with-build-config=bootstrap-debug --disable-nls 
> --enable-gnu-indirect-function --libdir=/usr/local/lib/gcc49 
> --libexecdir=/usr/local/libexec/gcc49 --program-suffix=49 
> --with-as=/usr/local/bin/as --with-gmp=/usr/local 
> --with-gxx-include-dir=/usr/local/lib/gcc49/include/c++/ 
> --with-ld=/usr/local/bin/ld --with-pkgversion='FreeBSD Ports Collection' 
> --with-system-zlib --with-ecj-jar=/usr/local/share/java/ecj-4.5.jar 
> --enable-languages=c,c++,objc,fortran,java --prefix=/usr/local 
> --localstatedir=/var --mandir=/usr/local/man --infodir=/usr/local/info/gcc49 
> --build=x86_64-portbld-freebsd11.0
> Thread model: posix
> gcc version 4.9.4 20160210 (prerelease) (FreeBSD Ports Collection)
> COLLECT_GCC_OPTIONS='-v' '-o' '/dev/null' '-isystem' '/usr/include' 
> '-mtune=generic' '-march=x86-64'
>  /usr/local/libexec/gcc49/gcc/x86_64-portbld-freebsd11.0/4.9.4/cc1plus -quiet 
> -v -isystem /usr/include - -quiet -dumpbase - -mtune=generic -march=x86-64 
> -auxbase - -version -o /tmp//ccNh006Z.s
> GNU C++ (FreeBSD Ports Collection) version 4.9.4 20160210 (prerelease) 
> (x86_64-portbld-freebsd11.0)
> compiled by GNU C version 4.9.4 20160210 (prerelease), GMP version 
> 5.1.3, MPFR version 3.1.3, MPC version 1.0.3
> GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
> ignoring nonexistent directory 
> "/usr/local/lib/gcc49/gcc/x86_64-portbld-freebsd11.0/4.9.4/../../../../../x86_64-portbld-freebsd11.0/include"
> ignoring duplicate directory "/usr/include"
> #include "..." search starts here:
> #include <...> search starts here:
>  /usr/include
>  /usr/local/lib/gcc49/include/c++/
>  /usr/local/lib/gcc49/include/c++//x86_64-portbld-freebsd11.0
>  /usr/local/lib/gcc49/include/c++//backward
>  /usr/local/lib/gcc49/gcc/x86_64-portbld-freebsd11.0/4.9.4/include
>  /usr/local/include
>  /usr/local/lib/gcc49/gcc/x86_64-portbld-freebsd11.0/4.9.4/include-fixed

I didn't realize the ports compiler was defaulting /usr/local/include
into the search path now.  It does not have /usr/local/lib in the
default library path as far as I

Re: svn commit: r297435 - head: still problems for stage 3 when gcc 4.2.1 is avoided (powerpc64 self-hosted build)

2016-03-31 Thread Mark Millard 

> On 2016-Mar-31, at 2:32 PM, Bryan Drewery  wrote:
> 
> On 3/31/16 2:23 PM, Mark Millard wrote:
>> I use the likes of:
>> 
 # diff -rq /usr/include /usr/local/include | grep "^Files "
>> to find what to rename for the duration of the system builds.
>> 
>> An example of what happens without the renames is below but I first note the 
>> use of the name dwarf_errmsg in /usr/include vs. in /usr/local/include 
>> (shown after the .h file rename but the build was with the normal file name):
>> 
> 
> Except for legacy, build-tools, bootstrap-tools, and cross-tools, none
> of /usr/include or /usr/local/include is supposed to be included.  In
> those phases though it is intended that /usr/include is used.  Not
> /usr/local/include though.
> 
> What package is providing /usr/local/include/libdwarf.h? 'pkg which
> /usr/local/include/libdwarf.h'  I ask so I can install it and recreate
> the issue and fix it.

Here is the list for the things I renamed, including for dwarf.h :

> # pkg which /usr/local/include/dwarf.h /usr/local/include/libdwarf.h 
> /usr/local/include/atf-c/defs.h /usr/local/include/iconv.h 
> /usr/local/include/histedit.h
> /usr/local/include/dwarf.h was installed by package libdwarf-20130207
> /usr/local/include/libdwarf.h was installed by package libdwarf-20130207
> /usr/local/include/atf-c/defs.h was installed by package atf-0.21
> /usr/local/include/iconv.h was not found in the database
> /usr/local/include/histedit.h was installed by package libedit-3.1.20150325_1

It looks like iconv.h is from something later removed but was not cleaned out 
at the time. I have /usr/local/include/readline/ material from the same time 
frame:

> # ls -lt /usr/local/include/
> .. . .
> -rw-r--r--   1 root  wheel   12733 Apr 22  2015 mpc.h
> -rw-r--r--   1 root  wheel9348 Mar 12  2015 renamed_iconv.h
> drwxr-xr-x   2 root  wheel 512 Mar 12  2015 readline
> # ls -lt /usr/local/include/readline
> total 80
> -rw-r--r--  1 root  wheel   3193 Mar 12  2015 rltypedefs.h
> -rw-r--r--  1 root  wheel   2438 Mar 12  2015 rlconf.h
> -rw-r--r--  1 root  wheel   1835 Mar 12  2015 rlstdc.h
> -rw-r--r--  1 root  wheel   3046 Mar 12  2015 tilde.h
> -rw-r--r--  1 root  wheel  10079 Mar 12  2015 history.h
> -rw-r--r--  1 root  wheel   3163 Mar 12  2015 keymaps.h
> -rw-r--r--  1 root  wheel   4577 Mar 12  2015 chardefs.h
> -rw-r--r--  1 root  wheel  37802 Mar 12  2015 readline.h

but "pkg which" reports those files as being from readline-6.3.8 .

I guess I can just delete would would normally have been 
/usr/local/include/iconv.h .

Back to quoting the earlier message:

> We likely just need to prioritize /usr/include over /usr/local/include
> for these phases, which gcc49 may have backwards since it has its prefix
> set to /usr/local from the ports build.
> 
 # find /usr/include/ -exec grep dwarf_errmsg {} \; -print
 #definedwarf_errmsg(error) dwarf_errmsg_()
 const char *dwarf_errmsg_(Dwarf_Error *);
 /usr/include/libdwarf.h
 # find /usr/local/include/ -exec grep dwarf_errmsg {} \; -print
 char* dwarf_errmsg(Dwarf_Error/*error*/);
 /usr/local/include/renamed_libdwarf.h
 #
>> So dwarf_errmsg is from /usr/local/include and dwarf_errmsg_ is from 
>> /usr/include .
>> 
>> The failure shows references to dwarf_errmsg instead of dwarf_errmsg_ --and 
>> dwarf_errmsg being undefined (dwarf_errno has similar issues):
>> 
 --
>> stage 3: cross tools
 --
 . . .
 --- ctfconvert.full ---
 /usr/local/bin/gcc49 -O2 -pipe 
 -I/usr/src/cddl/usr.bin/ctfconvert/../../../sys/cddl/compat/opensolaris 
 -I/usr/src/cddl/usr.bin/ctfconvert/../../../cddl/compat/opensolaris/include
  -I/usr/src/cddl/usr.b
 in/ctfconvert/../../../cddl/contrib/opensolaris 
 -I/usr/src/cddl/usr.bin/ctfconvert/../../../sys/cddl/contrib/opensolaris 
 -I/usr/src/cddl/usr.bin/ctfconvert/../../../cddl/contrib/opensolaris/head 
 -I/us
 r/src/cddl/usr.bin/ctfconvert/../../../cddl/contrib/opensolaris/tools/ctf/common
>>> -I/usr/src/cddl/usr.bin/ctfconvert/../../../cddl/contrib/opensolaris/tools/ctf/cvt
>>> -I/usr/src/cddl/usr.bin/ctfconvert/.
 ./../../sys/cddl/contrib/opensolaris/uts/common -DNEED_SOLARIS_BOOLEAN -g 
 -std=gnu99 
 -I/usr/obj/xtoolchain/powerpc.powerpc64/usr/src/tmp/legacy/usr/include  
 -static -L/usr/obj/xtoolchain/powerpc.power
 pc64/usr/src/tmp/legacy/usr/lib -o ctfconvert.full alist.o ctf.o 
 ctfconvert.o dwarf.o fixup_tdescs.o hash.o iidesc.o input.o list.o 
 memory.o merge.o output.o st_parse.o stabs.o stack.o strtab.o symbol
 .o tdata.o traverse.o util.o   -ldwarf  -lelf  -lelf  -lz  -lpthread 
 -legacy
 dwarf.o: In function `die_off':
 /usr/src/cddl/usr.bin/ctfconvert/../../../cddl/contrib/opensolaris/tools/ctf/cvt/dwarf.c:270:
  undefined reference to `dwarf_errmsg'
 dwarf.o:

Re: accessing a PCIe register from userspace through kmem or other ways ?

2016-03-31 Thread Ryan Stone 
On Thu, Mar 31, 2016 at 4:39 PM, John Baldwin  wrote:

> On Wednesday, March 30, 2016 11:20:51 AM Jim Harris wrote:
> > On Wed, Mar 30, 2016 at 10:47 AM, Luigi Rizzo 
> wrote:
> >
> > > Hi,
> > > I'd like to test the rate at which I can access device registers
> > > on a PCIe card, and was wondering whether I need to patch a device
> > > driver, or perhaps I can use /dev/kmem once I figure out where
> > > the registers are mapped ?
> > >
> >
> > You do not need to patch a device driver.  Have you looked at
> > libpciaccess?  This should give you everything you need.
>
> You can also look at what pciconf uses.  (It has a read_config() method
> that uses an ioctl on an fd of /dev/pci).
>

pciconf can only access the configuration space, right?  I believe that
Luigi is more interested in measuring the latency to a register mapped from
a BAR.
___
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: accessing a PCIe register from userspace through kmem or other ways ?

2016-03-31 Thread John Baldwin 
On Wednesday, March 30, 2016 11:20:51 AM Jim Harris wrote:
> On Wed, Mar 30, 2016 at 10:47 AM, Luigi Rizzo  wrote:
> 
> > Hi,
> > I'd like to test the rate at which I can access device registers
> > on a PCIe card, and was wondering whether I need to patch a device
> > driver, or perhaps I can use /dev/kmem once I figure out where
> > the registers are mapped ?
> >
> 
> You do not need to patch a device driver.  Have you looked at
> libpciaccess?  This should give you everything you need.

You can also look at what pciconf uses.  (It has a read_config() method
that uses an ioctl on an fd of /dev/pci).

-- 
John Baldwin
___
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: svn commit: r297435 - head: still problems for stage 3 when gcc 4.2.1 is avoided (powerpc64 self-hosted build)

2016-03-31 Thread Bryan Drewery 
On 3/31/16 2:23 PM, Mark Millard wrote:
> I use the likes of:
> 
>> > # diff -rq /usr/include /usr/local/include | grep "^Files "
> to find what to rename for the duration of the system builds.
> 
> An example of what happens without the renames is below but I first note the 
> use of the name dwarf_errmsg in /usr/include vs. in /usr/local/include (shown 
> after the .h file rename but the build was with the normal file name):
> 

Except for legacy, build-tools, bootstrap-tools, and cross-tools, none
of /usr/include or /usr/local/include is supposed to be included.  In
those phases though it is intended that /usr/include is used.  Not
/usr/local/include though.

What package is providing /usr/local/include/libdwarf.h? 'pkg which
/usr/local/include/libdwarf.h'  I ask so I can install it and recreate
the issue and fix it.

We likely just need to prioritize /usr/include over /usr/local/include
for these phases, which gcc49 may have backwards since it has its prefix
set to /usr/local from the ports build.

>> > # find /usr/include/ -exec grep dwarf_errmsg {} \; -print
>> > #definedwarf_errmsg(error) dwarf_errmsg_()
>> > const char *dwarf_errmsg_(Dwarf_Error *);
>> > /usr/include/libdwarf.h
>> > # find /usr/local/include/ -exec grep dwarf_errmsg {} \; -print
>> > char* dwarf_errmsg(Dwarf_Error/*error*/);
>> > /usr/local/include/renamed_libdwarf.h
>> > #
> So dwarf_errmsg is from /usr/local/include and dwarf_errmsg_ is from 
> /usr/include .
> 
> The failure shows references to dwarf_errmsg instead of dwarf_errmsg_ --and 
> dwarf_errmsg being undefined (dwarf_errno has similar issues):
> 
>> > --
> > >>> stage 3: cross tools
>> > --
>> > . . .
>> > --- ctfconvert.full ---
>> > /usr/local/bin/gcc49 -O2 -pipe 
>> > -I/usr/src/cddl/usr.bin/ctfconvert/../../../sys/cddl/compat/opensolaris 
>> > -I/usr/src/cddl/usr.bin/ctfconvert/../../../cddl/compat/opensolaris/include
>> >  -I/usr/src/cddl/usr.b
>> > in/ctfconvert/../../../cddl/contrib/opensolaris 
>> > -I/usr/src/cddl/usr.bin/ctfconvert/../../../sys/cddl/contrib/opensolaris 
>> > -I/usr/src/cddl/usr.bin/ctfconvert/../../../cddl/contrib/opensolaris/head 
>> > -I/us
>> > r/src/cddl/usr.bin/ctfconvert/../../../cddl/contrib/opensolaris/tools/ctf/common
>> -I/usr/src/cddl/usr.bin/ctfconvert/../../../cddl/contrib/opensolaris/tools/ctf/cvt
>> -I/usr/src/cddl/usr.bin/ctfconvert/.
>> > ./../../sys/cddl/contrib/opensolaris/uts/common -DNEED_SOLARIS_BOOLEAN -g 
>> > -std=gnu99 
>> > -I/usr/obj/xtoolchain/powerpc.powerpc64/usr/src/tmp/legacy/usr/include  
>> > -static -L/usr/obj/xtoolchain/powerpc.power
>> > pc64/usr/src/tmp/legacy/usr/lib -o ctfconvert.full alist.o ctf.o 
>> > ctfconvert.o dwarf.o fixup_tdescs.o hash.o iidesc.o input.o list.o 
>> > memory.o merge.o output.o st_parse.o stabs.o stack.o strtab.o symbol
>> > .o tdata.o traverse.o util.o   -ldwarf  -lelf  -lelf  -lz  -lpthread 
>> > -legacy
>> > dwarf.o: In function `die_off':
>> > /usr/src/cddl/usr.bin/ctfconvert/../../../cddl/contrib/opensolaris/tools/ctf/cvt/dwarf.c:270:
>> >  undefined reference to `dwarf_errmsg'
>> > dwarf.o: In function `die_sibling':
>> > /usr/src/cddl/usr.bin/ctfconvert/../../../cddl/contrib/opensolaris/tools/ctf/cvt/dwarf.c:288:
>> >  undefined reference to `dwarf_errmsg'
>> > dwarf.o: In function `die_child':
>> > /usr/src/cddl/usr.bin/ctfconvert/../../../cddl/contrib/opensolaris/tools/ctf/cvt/dwarf.c:305:
>> >  undefined reference to `dwarf_errmsg'
>> > dwarf.o: In function `die_tag':
>> > /usr/src/cddl/usr.bin/ctfconvert/../../../cddl/contrib/opensolaris/tools/ctf/cvt/dwarf.c:319:
>> >  undefined reference to `dwarf_errmsg'
>> > dwarf.o: In function `die_unsigned':
>> > /usr/src/cddl/usr.bin/ctfconvert/../../../cddl/contrib/opensolaris/tools/ctf/cvt/dwarf.c:370:
>> >  undefined reference to `dwarf_errmsg'
>> > dwarf.o:/usr/src/cddl/usr.bin/ctfconvert/../../../cddl/contrib/opensolaris/tools/ctf/cvt/dwarf.c:418:
>> >  more undefined references to `dwarf_errmsg' follow
>> > dwarf.o: In function `dw_read':
>> > /usr/src/cddl/usr.bin/ctfconvert/../../../cddl/contrib/opensolaris/tools/ctf/cvt/dwarf.c:1963:
>> >  undefined reference to `dwarf_errno'
>> > /usr/src/cddl/usr.bin/ctfconvert/../../../cddl/contrib/opensolaris/tools/ctf/cvt/dwarf.c:1971:
>> >  undefined reference to `dwarf_errmsg'
>> > /usr/src/cddl/usr.bin/ctfconvert/../../../cddl/contrib/opensolaris/tools/ctf/cvt/dwarf.c:1977:
>> >  undefined reference to `dwarf_errmsg'
>> > collect2: error: ld returned 1 exit status
>> > *** [ctfconvert.full] Error code 1
> 


-- 
Regards,
Bryan Drewery
___
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"

svn commit: r297435 - head: still problems for stage 3 when gcc 4.2.1 is avoided (powerpc64 self-hosted build)

2016-03-31 Thread Mark Millard 
Recent changes have been trying to make things like 
powerpc64-xtoolchain-gcc/powerpc64-gcc work better for buildworld/buildkernel.

I happen to do this on a powerpc64 context so the "cross build" is actually 
self-hosted. No gcc 4.2.1 is present and clang 3.8.0 and before have code 
generation problems for powerpc64 and powerpc so I avoid it for system builds, 
including for stage 3. (Also, clang for powerpc64 does not support building 
libstand: no soft-float support.)

As of my last test (-r297465) buildworld's stage 3 failed from implicit use of 
/usr/local/include materials unless I renamed various files there. In part this 
is because of my using gcc49 tools for CC and for CXX while using the 
powerpc64-gcc tools only for XCC and XCXX.

Is there a standard or recommended way to configure things to avoid such 
issues? Should powerpc64-gcc use be forced for CC and CXX as well as XCC and 
XCXX?

Should there be xtoolchain usage notes about avoiding /usr/local/include name 
conflicts and/or about how to assign CC/CXX/XCC/XCXX?

As long as I use gcc49 tools for CC and CXX I still must do things like 
renaming files in /usr/local/include to avoid them interfering with system 
headers:

> # find /usr/local/include/ -name 'renamed*' -print
> /usr/local/include/renamed_dwarf.h
> /usr/local/include/atf-c/renamed_defs.h
> /usr/local/include/renamed_iconv.h
> /usr/local/include/renamed_libdwarf.h
> /usr/local/include/renamed_histedit.h

I use the likes of:

> # diff -rq /usr/include /usr/local/include | grep "^Files "

to find what to rename for the duration of the system builds.

An example of what happens without the renames is below but I first note the 
use of the name dwarf_errmsg in /usr/include vs. in /usr/local/include (shown 
after the .h file rename but the build was with the normal file name):

> # find /usr/include/ -exec grep dwarf_errmsg {} \; -print
> #define   dwarf_errmsg(error) dwarf_errmsg_()
> const char*dwarf_errmsg_(Dwarf_Error *);
> /usr/include/libdwarf.h
> # find /usr/local/include/ -exec grep dwarf_errmsg {} \; -print

> char* dwarf_errmsg(Dwarf_Error/*error*/);
> /usr/local/include/renamed_libdwarf.h
> #

So dwarf_errmsg is from /usr/local/include and dwarf_errmsg_ is from 
/usr/include .

The failure shows references to dwarf_errmsg instead of dwarf_errmsg_ --and 
dwarf_errmsg being undefined (dwarf_errno has similar issues):

> --
> >>> stage 3: cross tools
> --
> . . .
> --- ctfconvert.full ---
> /usr/local/bin/gcc49 -O2 -pipe 
> -I/usr/src/cddl/usr.bin/ctfconvert/../../../sys/cddl/compat/opensolaris 
> -I/usr/src/cddl/usr.bin/ctfconvert/../../../cddl/compat/opensolaris/include 
> -I/usr/src/cddl/usr.b
> in/ctfconvert/../../../cddl/contrib/opensolaris 
> -I/usr/src/cddl/usr.bin/ctfconvert/../../../sys/cddl/contrib/opensolaris 
> -I/usr/src/cddl/usr.bin/ctfconvert/../../../cddl/contrib/opensolaris/head 
> -I/us
> r/src/cddl/usr.bin/ctfconvert/../../../cddl/contrib/opensolaris/tools/ctf/common
>  
> -I/usr/src/cddl/usr.bin/ctfconvert/../../../cddl/contrib/opensolaris/tools/ctf/cvt
>  -I/usr/src/cddl/usr.bin/ctfconvert/.
> ./../../sys/cddl/contrib/opensolaris/uts/common -DNEED_SOLARIS_BOOLEAN -g 
> -std=gnu99 
> -I/usr/obj/xtoolchain/powerpc.powerpc64/usr/src/tmp/legacy/usr/include  
> -static -L/usr/obj/xtoolchain/powerpc.power
> pc64/usr/src/tmp/legacy/usr/lib -o ctfconvert.full alist.o ctf.o ctfconvert.o 
> dwarf.o fixup_tdescs.o hash.o iidesc.o input.o list.o memory.o merge.o 
> output.o st_parse.o stabs.o stack.o strtab.o symbol
> .o tdata.o traverse.o util.o   -ldwarf  -lelf  -lelf  -lz  -lpthread -legacy
> dwarf.o: In function `die_off':
> /usr/src/cddl/usr.bin/ctfconvert/../../../cddl/contrib/opensolaris/tools/ctf/cvt/dwarf.c:270:
>  undefined reference to `dwarf_errmsg'
> dwarf.o: In function `die_sibling':
> /usr/src/cddl/usr.bin/ctfconvert/../../../cddl/contrib/opensolaris/tools/ctf/cvt/dwarf.c:288:
>  undefined reference to `dwarf_errmsg'
> dwarf.o: In function `die_child':
> /usr/src/cddl/usr.bin/ctfconvert/../../../cddl/contrib/opensolaris/tools/ctf/cvt/dwarf.c:305:
>  undefined reference to `dwarf_errmsg'
> dwarf.o: In function `die_tag':
> /usr/src/cddl/usr.bin/ctfconvert/../../../cddl/contrib/opensolaris/tools/ctf/cvt/dwarf.c:319:
>  undefined reference to `dwarf_errmsg'
> dwarf.o: In function `die_unsigned':
> /usr/src/cddl/usr.bin/ctfconvert/../../../cddl/contrib/opensolaris/tools/ctf/cvt/dwarf.c:370:
>  undefined reference to `dwarf_errmsg'
> dwarf.o:/usr/src/cddl/usr.bin/ctfconvert/../../../cddl/contrib/opensolaris/tools/ctf/cvt/dwarf.c:418:
>  more undefined references to `dwarf_errmsg' follow
> dwarf.o: In function `dw_read':
> /usr/src/cddl/usr.bin/ctfconvert/../../../cddl/contrib/opensolaris/tools/ctf/cvt/dwarf.c:1963:
>  undefined reference to `dwarf_errno'
>

Re: svn commit: r297435 - head: still problems for stage 3 when gcc 4.2.1 is avoided (powerpc64 self-hosted build)

2016-03-31 Thread Mark Millard 
The src.conf that I listed in the original message included the line:

> X_COMPILER_TYPE=gcc


So I'd already done that. Other suggestions?

===
Mark Millard
markmi at dsl-only.net

On 2016-Mar-31, at 2:26 PM, Bryan Drewery  wrote:

On 3/31/16 2:23 PM, Mark Millard wrote:
> Should there be xtoolchain usage notes about avoiding /usr/local/include name 
> conflicts and/or about how to assign CC/CXX/XCC/XCXX?
> 
> As long as I use gcc49 tools for CC and CXX I still must do things like 
> renaming files in /usr/local/include to avoid them interfering with system 
> headers:

Try setting X_COMPILER_TYPE=gcc as well.

-- 
Regards,
Bryan Drewery

___
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: svn commit: r297435 - head: still problems for stage 3 when gcc 4.2.1 is avoided (powerpc64 self-hosted build)

2016-03-31 Thread Bryan Drewery 
On 3/31/16 2:23 PM, Mark Millard wrote:
> Should there be xtoolchain usage notes about avoiding /usr/local/include name 
> conflicts and/or about how to assign CC/CXX/XCC/XCXX?
> 
> As long as I use gcc49 tools for CC and CXX I still must do things like 
> renaming files in /usr/local/include to avoid them interfering with system 
> headers:

Try setting X_COMPILER_TYPE=gcc as well.

-- 
Regards,
Bryan Drewery
___
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: Mixed ashift?

2016-03-31 Thread Dustin Marquess 
AH-HA! That makes perfect sense and is entirely obvious.. why didn't I
think of that?!

Thanks again!
-Dustin

On Thu, Mar 31, 2016 at 4:06 AM, Steven Hartland 
wrote:

> vfs.zfs.min_auto_ashift is only used when a device is added so you can set
> it add, then change.
>
>
>
> On 31/03/2016 07:15, Allan Jude wrote:
>
>> On 2016-03-31 02:13, Dustin Marquess wrote:
>>
>>> I have what I think is a pretty normal setup.. a bunch of HDDs plus 2
>>> SSDs
>>> (one ZIL, one SLOG).
>>>
>>> The HDDs are standard 512 byte sector drives.  The SSDs have 8k page
>>> sizes.
>>>
>>> In Illumos I added the SSDs to sd.conf and created the zpool and it shows
>>> the HDDs as ashift 9 and the SSDs as ashift 13, like normal:
>>>
>>> # zdb -C | grep ashift
>>>  ashift: 9
>>>  ashift: 9
>>>  ashift: 9
>>>  ashift: 9
>>>  ashift: 13
>>>
>>> The question is, how to replicate this in FreeBSD?  The old "gnop" method
>>> doesn't work anymore, and setting "vfs.zfs.min_auto_ashift=13" causes it
>>> to
>>> use 13 for the HDDs, which seems like a waste.  Is this not supported?
>>>
>>> Thanks!
>>> -Dustin
>>> ___
>>> 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"
>>>
>>> gnop should work, and you'd set the ashift before you add the devices.
>> So add the hard drives with it set to 9, then set it to 13 and add the
>> SLOG
>>
>>
> ___
> 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"
>
___
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"

FreeBSD_HEAD_amd64_gcc4.9 - Build #1141 - Fixed

2016-03-31 Thread jenkins-admin 
FreeBSD_HEAD_amd64_gcc4.9 - Build #1141 - Fixed:

Build information: 
https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc4.9/1141/
Full change log: 
https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc4.9/1141/changes
Full build log: 
https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc4.9/1141/console

Change summaries:

297444 by hselasky:
Fix bugs in currently unused bit searching loop.

MFC after:  3 days
Sponsored by:   Mellanox Technologies

297443 by adrian:
Add support for the Nuvoton NCT5104D.

Make it compile only for i386/amd64 for now as it's been tested there.
It's quite possible it'll show up elsewhere and we can enable it
for other architectures later.

Tested:

* PC Engines APU1C4

Submitted by:   Daniel Wyatt 
Reviewed by:adrian, loos
Differential Revision:  https://reviews.freebsd.org/D5389

297442 by bdrewery:
hosttools: Trim unneeded directories.

These should only be build tools that are in various Makefile.depend
as host dependencies.  Anything toolchain related is handled by
toolchain and bootstrap-tools currently.

Sponsored by:   EMC / Isilon Storage Division

297441 by pfg:
restore(8): fix use of uninitialized value.

Prevent uninitialized use of scalar newvol when jumping to gethdr.

CID:1006491

297439 by gnn:
Unbreak the RSS/PCBGROUp build.

297438 by bdrewery:
DIRDEPS_BUILD: Don't reset OBJROOT in sub-makes.

MAKEOBJDIRPREFIX is set to blank and exported from MAKELEVEL0 along
with OBJROOT exported.  In sub-makes OBJROOT is recalculated with
an empty MAKEOBJDIRPREFIX though.

Sponsored by:   EMC / Isilon Storage Division

297437 by bdrewery:
Regenerate

297436 by bdrewery:
Remove FAST_DEPEND reference missed in r297434.

297435 by bdrewery:
Fix the external GCC build after r297271 by setting -L /usr/lib.

GCC does add /usr/lib to the library search path but it comes after
/usr/local/lib which can find ports libraries such as libedit.so.  The
bad path comes in as 
/usr/local/lib/gcc/x86_64-portbld-freebsd11.0/5.3.0/../../../
which corresponds to /lib.

This partially reverts r297271.

Pointyhat to:   bdrewery
Sponsored by:   EMC / Isilon Storage Division

297434 by bdrewery:
Remove the old depend (mkdep) code and make FAST_DEPEND the one true way.

Reviewed by:emaste, hselasky (partial), brooks (brief)
Discussed on:   arch@
Sponsored by:   EMC / Isilon Storage Division
Differential Revision:  https://reviews.freebsd.org/D5742

297433 by bdrewery:
show-valid-targets: Indent each target 2 spaces.

Sponsored by:   EMC / Isilon Storage Division

297431 by bdrewery:
Remove redundant code imported into dirdeps.mk in r290956.

Sponsored by:   EMC / Isilon Storage Division

297430 by bdrewery:
show-valid-targets: Organize all targets by the all_machine_list.

Sponsored by:   EMC / Isilon Storage Division

297428 by bdrewery:
Move hosttools to Makefile.depend.host so it shows under host targets in 
show-valid-targets.

Sponsored by:   EMC / Isilon Storage Division

297427 by bdrewery:
show-valid-targets: Show host targets and also order all of the targets.

Sponsored by:   EMC / Isilon Storage Division

297426 by loos:
Enable SPI1 on Beaglebone Black.

SPI1 was chosen because SPI0 shares the gpio pins with I2C1.

Sponsored by:   Rubicon Communications (Netgate)

297425 by loos:
Use the AM33XX_IOPAD() MACRO which is easier to read (uses the same offset
of TRM).

While here remove i2c2_pins, it is already defined in
am335x-bone-common.dtsi.

Sponsored by:   Rubicon Communications (Netgate)

297424 by jamie:
Use osd_reserve / osd_jail_set_reserved, which is known to succeed.
Also don't work around nonexistent osd_register failure.

297423 by loos:
Add basic FDT support for the mx25l SPI flash.

Sponsored by:   Rubicon Communications (Netgate)

297422 by jamie:
Add osd_reserve() and osd_set_reserved(), which allow M_WAITOK allocation
of an OSD array,

297421 by mav:
Plug open count leak on zvol rename.

MFC after:  2 weeks

297420 by mav:
Switch from using make_dev_p() to make_dev_s() to close races.

297419 by loos:
Bump up the read and write timeouts.  The old value was too small for low
speed transfers.

Sponsored by:   Rubicon Communications (Netgate)

297418 by emaste:
libc: stop exporting cerror

i386 stopped exporting .cerror in r240152, and likewise for amd64 in
r240178. It is not used by other libraries on any platform, so apply
the same change to the remaining architectures.

Reviewed by:jhibbits, jilles
Sponsored by:   The FreeBSD Foundation
Differential Revision:  https://reviews.freebsd.org/D5774

297417 by pfg:
freopen(3): prevent uninitialized errno.

Revert completley r297408 (and r297407): this ends up touching errno,
which we are not allowed to do.

Pointed out by: ache, bde

297416 by hselasky:
Add new USB ID to UDL driver.

Submitted by:   Matthias Petermann 
PR: 201084

___
freebsd-current@freebsd.org mailing list

Re: Mixed ashift?

2016-03-31 Thread Steven Hartland 

vfs.zfs.min_auto_ashift is only used when a device is added so you can set it 
add, then change.


On 31/03/2016 07:15, Allan Jude wrote:

On 2016-03-31 02:13, Dustin Marquess wrote:

I have what I think is a pretty normal setup.. a bunch of HDDs plus 2 SSDs
(one ZIL, one SLOG).

The HDDs are standard 512 byte sector drives.  The SSDs have 8k page sizes.

In Illumos I added the SSDs to sd.conf and created the zpool and it shows
the HDDs as ashift 9 and the SSDs as ashift 13, like normal:

# zdb -C | grep ashift
 ashift: 9
 ashift: 9
 ashift: 9
 ashift: 9
 ashift: 13

The question is, how to replicate this in FreeBSD?  The old "gnop" method
doesn't work anymore, and setting "vfs.zfs.min_auto_ashift=13" causes it to
use 13 for the HDDs, which seems like a waste.  Is this not supported?

Thanks!
-Dustin
___
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"


gnop should work, and you'd set the ashift before you add the devices.
So add the hard drives with it set to 9, then set it to 13 and add the SLOG



___
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: Mixed ashift?

2016-03-31 Thread Allan Jude 
On 2016-03-31 02:13, Dustin Marquess wrote:
> I have what I think is a pretty normal setup.. a bunch of HDDs plus 2 SSDs
> (one ZIL, one SLOG).
> 
> The HDDs are standard 512 byte sector drives.  The SSDs have 8k page sizes.
> 
> In Illumos I added the SSDs to sd.conf and created the zpool and it shows
> the HDDs as ashift 9 and the SSDs as ashift 13, like normal:
> 
> # zdb -C | grep ashift
> ashift: 9
> ashift: 9
> ashift: 9
> ashift: 9
> ashift: 13
> 
> The question is, how to replicate this in FreeBSD?  The old "gnop" method
> doesn't work anymore, and setting "vfs.zfs.min_auto_ashift=13" causes it to
> use 13 for the HDDs, which seems like a waste.  Is this not supported?
> 
> Thanks!
> -Dustin
> ___
> 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"
> 

gnop should work, and you'd set the ashift before you add the devices.
So add the hard drives with it set to 9, then set it to 13 and add the SLOG

-- 
Allan Jude



signature.asc
Description: OpenPGP digital signature

Mixed ashift?

2016-03-31 Thread Dustin Marquess 
I have what I think is a pretty normal setup.. a bunch of HDDs plus 2 SSDs
(one ZIL, one SLOG).

The HDDs are standard 512 byte sector drives.  The SSDs have 8k page sizes.

In Illumos I added the SSDs to sd.conf and created the zpool and it shows
the HDDs as ashift 9 and the SSDs as ashift 13, like normal:

# zdb -C | grep ashift
ashift: 9
ashift: 9
ashift: 9
ashift: 9
ashift: 13

The question is, how to replicate this in FreeBSD?  The old "gnop" method
doesn't work anymore, and setting "vfs.zfs.min_auto_ashift=13" causes it to
use 13 for the HDDs, which seems like a waste.  Is this not supported?

Thanks!
-Dustin
___
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"