================
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.")
----------------
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.
================
Comment at: CMakeLists.txt:74
@@ +73,3 @@
+ if (APPLE)
+ message(FATAL_ERROR "LIBCXX_ENABLE_STATIC_ABI_LIBRARY is not supported on
OS X")
+ else()
----------------
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).
================
Comment at: cmake/Modules/HandleLibCXXABI.cmake:85
@@ -82,1 +84,3 @@
+ set(CXXABI_LIBNAME cxxabi_shared)
+ endif()
set(LIBCXX_LIBCPPABI_VERSION "2" PARENT_SCOPE)
----------------
EricWF wrote:
> compnerd wrote:
> > Why do you change the name of the library, the name should stay the same,
> > its the extension that changes (and I believe should be implicit based on
> > add_library).
> The actual library name ('libc++abi.so' or 'libc++abi.a') doesn't change.
> These are CMake target names for when libc++abi and libc++ are being built
> intree together.
Yeah, thats what happens when you look at a patch set out of order :-p.
================
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.
----------------
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.
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
