Date: Thu, 31 Mar 2016 20:33:08 -0700 From: Mark Millard <markmi@dsl-only.net> To: Bryan Drewery <bdrewery@FreeBSD.org> Cc: FreeBSD Current <freebsd-current@freebsd.org>, FreeBSD Toolchain <freebsd-toolchain@freebsd.org>, FreeBSD PowerPC ML <freebsd-ppc@freebsd.org>, Gerald Pfeifer <gerald@FreeBSD.org>, Warner Losh <imp@bsdimp.com> Subject: Re: svn commit: r297435 - head: still problems for stage 3 when gcc 4.2.1 is avoided (powerpc64 self-hosted build) Message-ID: <DD969902-BCA8-480B-B32F-07DCC6C3E32B@dsl-only.net> In-Reply-To: <7DEF97EC-D970-4F64-AF72-8939609A1D48@dsl-only.net> References: <5A0ACA76-6F1D-4975-9E59-2A64BB8EFC77@dsl-only.net> <56FD9757.6040709@FreeBSD.org> <9E3033D5-F416-4B78-97C2-0A0AABF5A49E@dsl-only.net> <56FDA5F9.1090601@FreeBSD.org> <481DA341-0DFC-4AF1-AD4D-56C5388FA8E3@dsl-only.net> <56FDBAA8.5060407@FreeBSD.org> <7DEF97EC-D970-4F64-AF72-8939609A1D48@dsl-only.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2016-Mar-31, at 8:14 PM, Mark Millard <markmi at dsl-only.net> wrote: >=20 > On 2016-Mar-31, at 5:02 PM, Bryan Drewery <bdrewery at FreeBSD.org> = wrote: >=20 >> This should be fine with my fix too. >>=20 >> Trying add this to your make.conf for now: >>=20 >> CFLAGS.gcc+=3D -isystem /usr/include >=20 > [Context note: I normally use: >=20 >> WITHOUT_CROSS_COMPILER=3D >> # >> WITH_FAST_DEPEND=3D >> WITH_LIBCPLUSPLUS=3D >> WITH_BOOT=3D >> WITH_CLANG=3D >> WITH_CLANG_IS_CC=3D >> WITH_CLANG_FULL=3D >> WITH_LLDB=3D >=20 >=20 > so clang is built by powerpc64-gcc's tools even though clang is not = used for the build. > ] >=20 > The result was almost immediate build failure: >=20 >> --- _bootstrap-tools-lib/clang/libllvmsupport --- >> --- APFloat.o --- >> In file included from = /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/include/llvm/Suppo= rt/AlignOf.h:19:0, >> from = /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/include/llvm/ADT/S= mallVector.h:18, >> from = /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/include/llvm/Suppo= rt/Allocator.h:24, >> from = /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/include/llvm/ADT/S= tringMap.h:18, >> from = /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/include/llvm/Suppo= rt/Host.h:17, >> from = /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/include/llvm/ADT/H= ashing.h:49, >> from = /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/include/llvm/ADT/A= rrayRef.h:13, >> from = /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/include/llvm/ADT/A= PInt.h:19, >> from = /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/include/llvm/ADT/A= PFloat.h:20, >> from = /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/APFloa= t.cpp:15: >> /usr/local/lib/gcc49/include/c++/cstddef:51:11: error: = '::max_align_t' has not been declared >> using ::max_align_t; > ^ >=20 > =3D=3D=3D > 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/includ= e > /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support > . > = /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/../../lib/clang/in= clude > /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. =3D=3D=3D 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) >>=20 >>>> # 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 >>>>=20 >>>> = /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. >>=20 >> 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. >=20 > This should be fine with my fix too. >=20 > Trying add this to your make.conf for now: >=20 > CFLAGS.gcc+=3D -isystem /usr/include >=20 --=20 Regards, Bryan Drewery
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?DD969902-BCA8-480B-B32F-07DCC6C3E32B>