Some of my ports (e.g., rpcs3, yuzu) require very recent libc++ but ports/ have to support up to 2 years old version shipped with a FreeBSD -RELEASE. Upstream projects also want to test recent libc++ on CI without waiting for FreeBSD to make a -RELEASE with such a version. So, can you enable libc++? Current ports/ workaround: GH_TUPLE+= llvm:llvm-project:llvmorg-13.0.1-rc1:libcxx CXXFLAGS+= -nostdinc++ -isystem${WRKDIR}/libcxx_prefix/include/c++/v1 LDFLAGS+= -nostdlib++ -L${WRKDIR}/libcxx_prefix/lib -l:libc++.a -lcxxrt pre-configure: bundled-libcxx bundled-libcxx: @${SETENV} ${CONFIGURE_ENV} ${CMAKE_BIN} ${CMAKE_ARGS:M*Ninja*} \ -DCMAKE_INSTALL_PREFIX:PATH=${WRKDIR}/libcxx_prefix \ -B ${WRKDIR}/libcxx_build -S ${WRKSRC_libcxx}/libcxx @${DO_MAKE_BUILD:NDESTDIR*} install -C ${WRKDIR}/libcxx_build
I'm not a fan of adding libc++ to devel/llvm*. GCC's baked in libstdc++ has historically been an unending nightmare of cross-threaded dependencies. I am fairly certain this will break in at least some cases where the base C++ and libc++ with default build options have different ABIs. I'm open to finding a better solution than building a per-port libc++, but I'm not sold on maintaining libc++ as part of the compiler. I need to understand how this won't become a mess of debugging other people's C++ linkage issues.
(In reply to Brooks Davis from comment #1) Stronger?: Is not a goal to be able to use llvm13 materials to buildworld and buildkernel without changing the FreeBSD ABI? (libc++ need not keep compatibility from version to version.) It is one way of avoiding a chunk of the time buildworld takes takes, given a llvm13 package is available and installed. So, at least enough control to allow use of the system libc++ and llvm13 materials would seem to be needed. (The point is not really llvm13 specific long term: just an example.) Do not get me wrong, I'd like to be able to experiment with the modern libc++ as well. (In fact, I do not normally do the llvm13 style buildworld's and buildkernel's. But I have on occasion resorted to such.) May be a lang/llvm13 and devel/llvm13 with differing command names and such? (This may be absurd overall. I'm not familiar with what all would be involved in having both.)
(In reply to Brooks Davis from comment #1) > different ABIs Can be solved in 2 ways: - Build libc++ from llvm13 but don't use by default - Disable shared libc++ library in llvm13 Alternatively, devel/libc++ can be resurrected or bug 215193 unstalled.