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