I've now polished WANT_CXX enough to commit it. It's simply there to choose base clang, or gcc4 according to the architecture.
I also introduced LIBECXX so that wantlib can be adjusted without needing a lot of conditionals. lang/clang is more complex so this will happen later. I'm in the process of committing the local changes I have so that anybody can reproduce the build. I still have some uncommitted WANT_CXX, that I will commit when the build has progressed past that. So far, a lot of things actually build. boost is still not building and a problem, and quite a few multimedia libraries also want clang. brad might want to get involved, as he's responsible for a lot of that code ;) I've solved the qt5base issue, which was mostly qmake doing some really strange things which require us to be explicit with respect to libc++ includes. Looking some more at the tree, there are quite a few significant ports that actually build fine, but use gcc4 right now. Notable examples are postgresql, mongodb, php*, node, chromium and iridium... That's on my next pass to look at, not that it's a large problem for amd64 if they're self-contained/not contain C++, but because moving them to clang would enable them on aarch64. There are some base issues that will need solving: - the infamous binutils/clang pie relocations. I think that -pg also does not work, as exemplified by net/iperf3.log: cc -o .libs/iperf3_profile -pg -g -O2 -pipe -Wall -pg -g iperf3_profile-main.o iperf3_profile-cjson.o iperf3_profile-iperf_api.o iperf3_profile-iperf_error.o iperf3_profile-iperf_client_api.o iperf3_profile-iperf_locale.o iperf3_profile-iperf_server_api.o iperf3_profile-iperf_tcp.o iperf3_profile-iperf_udp.o iperf3_profile-iperf_sctp.o iperf3_profile-iperf_util.o iperf3_profile-net.o iperf3_profile-tcp_info.o iperf3_profile-tcp_window_size.o iperf3_profile-timer.o iperf3_profile-units.o -L.libs -liperf -lm -Wl,-rpath-link,/usr/local/lib /usr/bin/ld: /usr/bin/../lib/libc_p.a(assert.po): relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC /usr/bin/../lib/libc_p.a: could not read symbols: Bad value - thread local storage is actually used by about 4 or 5 ports that simply #define it away if it's not available! So those ports are NOT thread-safe right now!!! and emulated-tls wants -pthread. Right now, the "solution" would be to build libraries twice... since there aren't that many, it's actually possible, though cumbersome...
