This is an archive of the discontinued LLVM Phabricator instance.

[libcxx] Allow linking against the MSVC static CRT
ClosedPublic

Authored by mstorsjo on Jul 18 2023, 1:00 AM.

Details

Summary

This respects the CMAKE_MSVC_RUNTIME_LIBRARY option for selecting
the right CRT to use.

Add a CI configuration that tests building this way.

Based on a patch by Andrew Ng.

The test config files end up accumulating and duplicating a fair
bit of cmake-specific logic here; if preferred, we could also add
that in libcxx/test/CMakeLists.txt and export a few more variables
to cmake-bridge.cfg.in instead.

Diff Detail

Event Timeline

mstorsjo created this revision.Jul 18 2023, 1:00 AM
Herald added a project: Restricted Project. · View Herald TranscriptJul 18 2023, 1:00 AM
Herald added a subscriber: arichardson. · View Herald Transcript
mstorsjo requested review of this revision.Jul 18 2023, 1:00 AM
Herald added a project: Restricted Project. · View Herald TranscriptJul 18 2023, 1:00 AM
Herald added a reviewer: Restricted Project. · View Herald Transcript

This SGTM, but I like to see some feedback of the reviewers more familiar with Windows.

andrewng accepted this revision.Jul 19 2023, 9:21 AM

LGTM, although I slightly prefer my patch where it would be possible to build both the shared and static versions of libcxx. However, this patch is more simple which is good too.

Actually, whilst looking at D155561, I see what you mean by duplication in the test configs. AFAICT, they only differ in the definitions in the compile_flags. I guess it would be good to somehow avoid all this duplication.

Actually, whilst looking at D155561, I see what you mean by duplication in the test configs. AFAICT, they only differ in the definitions in the compile_flags. I guess it would be good to somehow avoid all this duplication.

Yep. I don’t mind changing it, either in this patch or as a separate later follow-up, to running this logic in cmake and exporting the variables needed in the test config - I’ll leave that call up to the libcxx maintainers.

although I slightly prefer my patch where it would be possible to build both the shared and static versions of libcxx. However, this patch is more simple which is good too.

Yeah, this is very simple at least. If strictly needed, we can add options later. But due to the dllimport attributes in headers, you can’t really use a build of both static and shared anyway, unless users define the macro for disabling visibility before including libcxx headers. So with clang-cl, you pretty much need to choose either static or shared, not both. And at that point, the single variable CMAKE_MSVC_RUNTIME_LIBRARY gives enough control anyway.

although I slightly prefer my patch where it would be possible to build both the shared and static versions of libcxx. However, this patch is more simple which is good too.

Yeah, this is very simple at least. If strictly needed, we can add options later. But due to the dllimport attributes in headers, you can’t really use a build of both static and shared anyway, unless users define the macro for disabling visibility before including libcxx headers.

That's basically how I manually switched between "static" and "shared" builds by disabling the "visibility" since I already had to manually add the include paths for the libcxx headers. Ideally, the clang-cl driver would sort this all out based on selected "runtime" type and use of libcxx. But this support is still missing, along with the issues related to compiler-rt. It's very much DIY at the moment...

although I slightly prefer my patch where it would be possible to build both the shared and static versions of libcxx. However, this patch is more simple which is good too.

Yeah, this is very simple at least. If strictly needed, we can add options later. But due to the dllimport attributes in headers, you can’t really use a build of both static and shared anyway, unless users define the macro for disabling visibility before including libcxx headers.

That's basically how I manually switched between "static" and "shared" builds by disabling the "visibility" since I already had to manually add the include paths for the libcxx headers. Ideally, the clang-cl driver would sort this all out based on selected "runtime" type and use of libcxx. But this support is still missing, along with the issues related to compiler-rt. It's very much DIY at the moment...

Yep - that's why it's probably best to keep things simple and not add more options than necessary for now. One can configure exactly what one wants anyway by doing two separate builds with LIBCXX_ENABLE_SHARED=OFF and LIBCXX_ENABLE_STATIC=OFF.

This revision is now accepted and ready to land.Jul 24 2023, 11:02 AM
This revision was automatically updated to reflect the committed changes.