[libcxx-commits] [PATCH] D116689: [libunwind][libcxxabi] Use object libraries in the build

Tue Feb 8 15:09:12 PST 2022

phosek added a comment.

In D116689#3223513 <https://reviews.llvm.org/D116689#3223513>, @smeenai wrote:

> The build used to be set up with object libraries, and then @ldionne explicitly changed it to not do so, so that e.g. the shared library is built as PIC by default and the static library isn't. This change would regress that.

To clarify, I'm not trying to reuse object library between static and shared library as was the case in the past, that's undesirable for the reason you mentioned. I'm just adding an intermediate step: before we would build static library directly, now we build object library first and then archive it into static library. The reason for doing that is now we can depend on the object library from other targets (for example, libc++ can directly link libc++abi object library).

In D116689#3306237 <https://reviews.llvm.org/D116689#3306237>, @ldionne wrote:

>> That's also a prerequisite for using `OSX_ARCHITECTURES` in CMake to build libcxx as universal library
>
> I'm especially curious about this -- why does that require using object libraries?

https://github.com/llvm/llvm-project/blob/bbddd19ec723a15ea1558cce5e47cb2460fa8e24/libcxx/utils/merge_archives.py script we use for merging archives (this is used when combining `libc++abi.a` into `libc++.a`) uses `ar` to extract archives into a temporary directory and then repackage them into a new combined archive. That doesn't work for universal static libraries since those aren't traditional UNIX archives (at least I haven't found a way to do that with existing tooling).

This change skips the extraction and repackaging step altogether and instead packages all objects that should go into the final library directly (through CMake dependencies). I think that approach is also more efficient (no extraction and repackaging) and explicit (CMake and Ninja know exactly which files form the final archive) at slight increase in CMake code complexity which IMO is a good tradeoff.

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D116689/new/

https://reviews.llvm.org/D116689