This is an archive of the discontinued LLVM Phabricator instance.

[llvm-lit] copy CRT/STL DLLs into the output directory
AbandonedPublic

Authored by strega-nil on Aug 17 2023, 2:58 PM.

Details

Summary

It turns out that the STL requires you to place the DLLs into the
directory of the executable; else, msvcp140.dll will be taken from
C:\Windows\System32 (which is unsupported).

This was discovered because of the recent constexpr mutex change;
see [microsoft/STL#3824][]. Especially the fuzzer unit tests fail
completely with the mutex changes.

[microsoft/STL#3824]: https://github.com/microsoft/STL/issues/3824

Diff Detail

Event Timeline

strega-nil created this revision.Aug 17 2023, 2:58 PM
Herald added a project: Restricted Project. · View Herald TranscriptAug 17 2023, 2:58 PM
Herald added a subscriber: delcypher. · View Herald Transcript
strega-nil requested review of this revision.Aug 17 2023, 2:58 PM
Herald added a project: Restricted Project. · View Herald TranscriptAug 17 2023, 2:58 PM
strega-nil planned changes to this revision.Aug 17 2023, 3:45 PM
strega-nil added inline comments.
llvm/utils/lit/lit/TestRunner.py
2079

This doesn't work with clang's version of lit, only with our msvc version of lit, since the output directory is shared; I'm going to need to figure out a better way to do this, that works with either.

strega-nil marked an inline comment as not done.Aug 17 2023, 3:46 PM

Fix the code to work with built-in lit/main.py

The code in the first commit was designed to work with MSVC's internal
lit/msvc_main.py; the new code works with either.

oops, missed a commit (ignore)

rnk added a comment.Aug 22 2023, 4:15 PM

I'm not that familiar with the typical compatibility requirements for DLLs in the Windows system folder, but it seems pretty disruptive to ship a DLL in the system folder, and then ship ABI incompatible changes without increasing the version number. Wouldn't this all work if the STL increased the version number of msvcp140.dll instead?

llvm/utils/lit/lit/run.py
73

This is typically quite a lot of directories, so this doesn't seem like a great solution. I looked at the DLL search path docs, and it looks like the system directory (C:\Windows\System32) precedes PATH, which is unfortunate. Is there no other way to inject a DLL search path *before* the system directory? SxS manifests seem like the most promising option, but that doesn't sound like fun either.

strega-nil abandoned this revision.Aug 23 2023, 2:23 PM

It turns out I misunderstood how this release process works; it is _only_ important inside our internal test harness, not inside the LLVM public test harness; I apologize for opening this non-useful PR.