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 DreweryReceived on Fri Apr 01 2016 - 01:14:25 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:03 UTC