[CMake][libcxxabi] Support merging archives when statically linking unwinder

[phosek]

Summary

When using LLVM unwinder and static unwinder option is set, merge
libc++abi.a and libunwind.a into a single archive. libc++ already
supports merging libc++abi.a and libc++.a into a single archive; with
this change, it is possible to also include libunwind.a in the same
archive which is useful when doing static link and using libc++ as
a default C++ library and compiler-rt as a default runtime library.

[jroelofs]

What's the advantage to using python for this over doing it directly in CMake?

[phosek]

In D39949#922920, @jroelofs wrote:

What's the advantage to using python for this over doing it directly in CMake?

The only one I can think of is the consistency with libc++: I've blatantly copied the implementation used by libc++, but I'd be perfectly happy to redo this in plain CMake if people are fine with it (and also update libc++ to use the same approach).

[phosek]

I've modified the patch to use plain CMake, PTAL.

[beanz]

Rather than hand rolling ar commands, could we make libunwind, libcxxabi, and libcxx produce object libraries, then we could just create normal static library targets with the object libraries as sources.

Thoughts?

[phosek]

That's a great suggestion! libunwind and libc++abi already produce object libraries so using that approach makes this change even simpler.

[beanz]

One small nitpick, otherwise LGTM!

src/CMakeLists.txt

157 ↗

(On Diff #123288)

You should be able to do this with list(APPEND ...) instead of set.

[mstorsjo]

I presume that this only works as long as you build libunwind and libcxxabi together in a single build instead of building them standalone? (Or put another way; when building llvm+clang+lld on linux, for linux, intended to be used as cross compiler for windows - is there any way to build libunwind+libcxxabi+libcxx within the same source tree for i686,x86_64,arm,arm64 windows/mingw?)

[beanz]

@mstorsjo that is the problem that the LLVM/runtimes directory solves. It supports building all the runtime libraries as a single build with one build-tree per target and the management of separate build trees is handled by the build system.

[mstorsjo]

In D39949#929055, @beanz wrote:

@mstorsjo that is the problem that the LLVM/runtimes directory solves. It supports building all the runtime libraries as a single build with one build-tree per target and the management of separate build trees is handled by the build system.

Oh, interesting - I'll have to look into that and see how well it works for my case!

libcxxabi/trunk/src/CMakeLists.txt

set_target_properties(cxxabi_shared
                             "1"
                           VERSION
                             "1.0")
   list(APPEND LIBCXXABI_TARGETS "cxxabi_shared")
 endif()
 
 # Build the static library.
 if (LIBCXXABI_ENABLE_STATIC)
-  add_library(cxxabi_static STATIC $<TARGET_OBJECTS:cxxabi_objects>)
+  set(cxxabi_static_sources $<TARGET_OBJECTS:cxxabi_objects>)
+  if (LIBCXXABI_USE_LLVM_UNWINDER AND LIBCXXABI_ENABLE_STATIC_UNWINDER)
+    if (TARGET unwind_static OR HAVE_LIBUNWIND)
+      list(APPEND cxxabi_static_sources $<TARGET_OBJECTS:unwind_objects>)
+    endif()
+  endif()
+  add_library(cxxabi_static STATIC ${cxxabi_static_sources})
   target_link_libraries(cxxabi_static ${LIBCXXABI_LIBRARIES})
   set_target_properties(cxxabi_static
                         PROPERTIES
                           CXX_EXTENSIONS
                             OFF
                           CXX_STANDARD
                             11
                           CXX_STANDARD_REQUIRED