From owner-freebsd-toolchain@freebsd.org Fri Apr 1 03:14:25 2016 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0BEC2AE45F5 for ; Fri, 1 Apr 2016 03:14:25 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-157.reflexion.net [208.70.211.157]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C372616C3 for ; Fri, 1 Apr 2016 03:14:24 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 788 invoked from network); 1 Apr 2016 03:14:45 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 1 Apr 2016 03:14:45 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v7.90.1) with SMTP; Thu, 31 Mar 2016 23:14:13 -0400 (EDT) Received: (qmail 2458 invoked from network); 1 Apr 2016 03:14:13 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with SMTP; 1 Apr 2016 03:14:13 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 3DD6C1C4075; Thu, 31 Mar 2016 20:14:16 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: svn commit: r297435 - head: still problems for stage 3 when gcc 4.2.1 is avoided (powerpc64 self-hosted build) From: Mark Millard In-Reply-To: <56FDBAA8.5060407@FreeBSD.org> Date: Thu, 31 Mar 2016 20:14:21 -0700 Cc: FreeBSD Current , FreeBSD Toolchain , FreeBSD PowerPC ML , Gerald Pfeifer , Warner Losh Content-Transfer-Encoding: quoted-printable Message-Id: <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> To: Bryan Drewery X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2016 03:14:25 -0000 On 2016-Mar-31, at 5:02 PM, Bryan Drewery = wrote: > 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 [Context note: I normally use: > 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 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/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; ^ =3D=3D=3D 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) >>=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