[libcxx-commits] [PATCH] D120719: [runtimes] Always configure libc++abi before libc++

[Martin Storsjö via Phabricator via libcxx-commits]

mstorsjo added inline comments.


================
Comment at: libcxx/cmake/caches/MinGW.cmake:9
 set(LIBCXX_ENABLE_STATIC_ABI_LIBRARY ON CACHE BOOL "")
+set(LIBCXXABI_HERMETIC_STATIC_LIBRARY OFF CACHE BOOL "")
 
----------------
This would now start dllexporting cxxabi symbols in a full-static configuration, too, which isn’t desired. So if we’d want to set this flag, we should only do it in the mingw-dll configuration, not in mingw-static. (This won’t be noticed in CI, but it would produce static libraries that don’t do the right thing in practice.)

But overall; the setup of the linkage between libcxxabi and libcxx for windows has worked based solely on the usual `LIBCXX_ENABLE_SHARED` flags, for a couple releases now (which is good - the fewer options needed for getting it right, the better); I’d we’d now require setting the hermetic flag for controlling it, it’d be a breakage for such configurations out there. (I.e., if this code change requires changes to the CI script or the cmake caches, it will also break some users setups similarly.)

I’m not opposed to making the libcxxabi visibility mechanism for windows share internal logic with the hermetic library option though, but for the windows configuration, the user shouldn’t need to know about this option as it hasn’t been needed so far. (And if the user would start to need to use it, where things worked before, I’d like a proper deprecation cycle to let users migrate their build setups without breakage.)

Could we change the logic on libcxxabi cmakelists line 305 to `(LIBCXX_ENABLE_SHARED OR UNSET LIBCXX_ENABLE_SHARED) …`? I.e. the same logic we have right now, but treating unset as on (which is the default).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D120719