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