================ Comment at: CMakeLists.txt:64 @@ -63,2 +63,3 @@ option(LIBCXX_INSTALL_SUPPORT_HEADERS "Install libc++ support headers." ON) +option(LIBCXX_ENABLE_STATIC_ABI_LIBRARY "Statically link the ABI library" OFF) set(LIBCXX_SYSROOT "" CACHE STRING "Use alternate sysroot.") ---------------- compnerd wrote: > Maybe this should be something like LIBCXX_STATIC_LIBCXXABI. Otherwise, we > need checks for the case that we are trying to use libsupc++/libcxxrt and > don't have a static version available. Perhaps. Since the option is `OFF` by default I don't think we *need* checks. I have no problem with these cases failing to link because the library is missing. If a user enables this option they should know that they have a static version of the library available.
================ Comment at: CMakeLists.txt:74 @@ +73,3 @@ + if (APPLE) + message(FATAL_ERROR "LIBCXX_ENABLE_STATIC_ABI_LIBRARY is not supported on OS X") + else() ---------------- compnerd wrote: > Any reason to not support this on Darwin really? I think that we can build a > DSO for libc++ and just grab the $<TARGET_OBJECTS:c++abi> (or a static > archive/library). Because linking libc++ on Darwin is already a mess and it would need to be cleaned up first. I also don't see the motivation to support this on Darwin because libc++ reexports libc++abi.dynlib. ================ Comment at: test/CMakeLists.txt:47 @@ -46,1 +46,3 @@ pythonize_bool(LIBCXX_ENABLE_MONOTONIC_CLOCK) + # The tests shouldn't link to any ABI library when it has been linked into + # libc++ statically. ---------------- compnerd wrote: > EricWF wrote: > > compnerd wrote: > > > Can you explain why this is correct? The tests are meant to test > > > libc++abi. They should link to it either statically or dynamically as > > > built. The libc++ tests however, should not. > > Because when libc++ statically links to libc++abi then all of the symbols > > from libc++abi should be available via libc++. If we don't do this and > > always link the tests to libc++abi then it could hide errors where libc++ > > doesn't properly expose the required symbols. > Agreed, but the libc++abi tests shouldn't try to pull the symbols indirectly > from libc++. They should have direct access to libc++abi symbols. This shouldn't affect the libc++abi tests because they don't use the `lit.site.cfg` generated by libc++. http://reviews.llvm.org/D8017 EMAIL PREFERENCES http://reviews.llvm.org/settings/panel/emailpreferences/ _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
