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 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 _______________________________________________ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"