CXXSTD=c++11

[Mark Millard]

[Just a few notes related to some points in the exchange.]

powerpc and powerpc64 are in the same boat as mips and sparc for clang's overall status: clang does not work yet, independent of any FreeBSD issues that might exist if clang's code generation was okay. (See https://llvm.org/bugs/show_bug.cgi?id=25780 and what it "depends on".)

I've been able to buildworld using WITH_LIB32= via powerpc64-xtoolchain-gcc/powerpc64-gcc with the libcxxrt _Static_assert disabled but what was built has never worked because of some of the code in the crtbeginS.o produced. (See https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=206123 .)

powerpc64-xtoolchain-gcc/powerpc64-gcc as it is currently built when used on a powerpc64 (self hosting "cross builds" for buildworld) historically looks in and prefers /usr/local/include/ include files so I first rename files that caused me problems, for example:

> # ls /usr/local/include/renamed_*
> /usr/local/include/renamed_dwarf.h	/usr/local/include/renamed_iconv.h	/usr/local/include/renamed_libdwarf.h

I do not know if the -isystem change(s) will improve this to prefer the likes of (in my context) /usr/obj/xtoolchain/powerpc.powerpc64/usr/src/tmp/usr/include/c++/v1 and/or /usr/obj/xtoolchain/powerpc.powerpc64/usr/src/tmp/usr/include or not. It is too bad that powerpc64-gcc automatically looks in /usr/local/include .

Direct use of the live-system's /usr/include/c++/v1 area would be the wrong place if that code had updates. As I understand things, ${WORLDTMP} use is appropriate in forming the include directory paths (in my context: /usr/obj/xtoolchain/powerpc.powerpc64/usr/src/tmp prefixes).


===
Mark Millard
markmi at dsl-only.net