[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 _______________________________________________ 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"
