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

[Petr Hosek via Phabricator via libcxx-commits]

phosek added a comment.

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

> In D116689#3306286 <https://reviews.llvm.org/D116689#3306286>, @phosek wrote:
>
>> 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).
>
> I agree with your reasoning and I'm not suggesting you go this route, but just as a generate note, libtool (and the LLVM version llvm-libtool-darwin) should be able to handle universal archives pretty transparently; in particular, you can tell libtool to construct a static library from multiple existing static libraries directly (and it'll handle universal archives as expected) instead of having to do a manual extraction and repackaging.

Good to know, thanks for pointing that out. I also found out that `llvm-ar` recently gained `L` option that allows appending to an archive without having to extract it.

The problem is that these are extensions only supported by LLVM tools, so if we started relying on those unconditionally, we would break compatibility with non-LLVM tools which may undesirable.

We could also have conditional logic: if you're using LLVM tools, use the LLVM-specific options, otherwise use a fallback, but that's going to result in even more complexity.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D116689