[PATCH] [libcxx] Add support for linking libc++ against a static ABI library.

[Eric Fiselier]

================
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/