[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