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

Fri Apr 1 03:33:11 UTC 2016

On 2016-Mar-31, at 8:14 PM, Mark Millard <markmi at dsl-only.net> wrote:
> 
> On 2016-Mar-31, at 5:02 PM, Bryan Drewery <bdrewery at FreeBSD.org> 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 <bdrewery at FreeBSD.org> wrote:

> On 3/31/16 4:42 PM, Mark Millard wrote:
>> On 2016-Mar-31, at 3:34 PM, Bryan Drewery <bdrewery at FreeBSD.org> 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.h		ppc-asm.h		spu2vmx.h		stdatomic.h		stdint-gcc.h		unwind.h
>>>> float.h			objc			ppu_intrinsics.h	ssp			stdbool.h		stdint.h		varargs.h
>>>> htmintrin.h		omp.h			si2vmx.h		stdalign.h		stddef.h		stdnoreturn.h		vec_types.h
>>>> htmxlintrin.h		paired.h		spe.h			stdarg.h		stdfix.h		tgmath.h
>>>> 
>>>> /usr/local/lib/gcc49/gcc/powerpc64-portbld-freebsd11.0/4.9.4/include-fixed:
>>>> README		libmilter	limits.h	netinet		stddef.h	stdio.h		stdlib.h	sys		syslimits.h	unistd.h	wchar.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