[libcxx-commits] [PATCH] D144734: [libcxx] Enable support for static and debug Windows runtimes

Martin Storsjö via Phabricator via libcxx-commits libcxx-commits at lists.llvm.org
Wed Jun 14 13:46:45 PDT 2023


mstorsjo added a comment.

In D144734#4422521 <https://reviews.llvm.org/D144734#4422521>, @rnk wrote:

> We should prioritize fixing the int128 issues. I've lost track of the next step. Let me know where to focus if I can help move it along. I can see that it's blocking a lot of things. Is Tobias's linker library autodiscovery the next step? What prevents us from emitting the appropriate autolinking directives today in LLVM?

I think the private mail discsussion between us from around May 26th had a lot of good conclusions from yourself regarding how to move forward with this; we should probably mirror those conclusions and/or maybe the whole discussion somewhere public.

Getting the autolinking directives emitted properly (only when needed, in order to not break setups where clang_rt.builtins isn't available, e.g. cross compiling with just a bundled MSVC/WinSDK, without building clang runtimes for all MSVC cross targets) probaby is the biggest hurdle. As you noted there, due to `LLVM_ENABLE_PER_TARGET_RUNTIME_DIR`, the `clang_rt.builtins` files can exist with a couple different names and in a few different directories.

Once we do have autolinking directives emitted, we're almost there; for x86 targets, MSVC already does ship `clang_rt.builtins-<arch>.lib`, available in the link path. So there we don't really even need the linker library directory support either, unless we want the latest compiler-rt (and for arm) that we'd build ourselves, instead of whatever was shipped with MSVC.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D144734



More information about the libcxx-commits mailing list