[libcxx-commits] [PATCH] D120982: [libcxxabi] Fix cmake order dependency wrt dllexporting

Martin Storsjö via Phabricator via libcxx-commits libcxx-commits at lists.llvm.org
Fri Mar 4 08:08:50 PST 2022


mstorsjo added a comment.

In D120982#3359946 <https://reviews.llvm.org/D120982#3359946>, @ldionne wrote:

> Like I said in D120719 <https://reviews.llvm.org/D120719>, I am not fond of this approach because it preserves the circular dependency between libc++ and libc++abi. My primary goal is that libc++abi doesn't have to have too much knowledge about how libc++ is configured (ideally it would require no such knowledge).
>
> To this end, we could either:
>
> 1. Ask Windows vendors to bite the bullet and start defining `LIBCXXABI_HERMETIC_STATIC_LIBRARY` manually, or
> 2. Set `LIBCXXABI_HERMETIC_STATIC_LIBRARY` to `ON` by default on Windows.

I understand that you want to untangle the circular dependencies between the two libraries - I totally see the value in that. But I ask that we don't do it in a way that break users upfront without a deprecation period over a release to let users migrate to the new way of configuring the interdependencies of these libraries.

We can't blindly set the `LIBCXXABI_HERMETIC_STATIC_LIBRARY` to one value or another as that breaks either build config (but "breaking" the static build isn't visible in the CI setup). When building with `LIBCXX_ENABLE_STATIC_ABI_LIBRARY=ON` (which is essentially the only way that works to combine the libraries on Windows), `LIBCXXABI_HERMETIC_STATIC_LIBRARY` would have to be set to the negation of `LIBCXX_ENABLE_SHARED`. (Builds with shared+static get an incorrect version for the static library though - that's a longer standing issue I've planned to look into in the future.)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D120982



More information about the libcxx-commits mailing list