Case-sensitive naming for DLLs sometimes is not respected
dmikushin opened this issue · 4 comments
When running cl.exe and other components in WSL without wine, it turns out some of the filenames case-sensitivity is not properly respected. For example, vcruntime140.dll instead of the required VCRUNTIME140.dll. Wine sorts out this disagreement for us, right?
I would like to track down the reason of this issue. Perhaps, msitools/msiextract or vsix zip extraction misses some case-sensitivity logic?
Can you be more specific as to what the exact issue is and how to reproduce it? You're installing MSVC within WSL using these scripts, and then execute cl.exe without using wine?
When running things on Unix, using these scripts, Wine takes care of a lot of the case insensitivity, yes. But in addition to that, install.sh does some amount of extra lowercasing of files (lowercasing the names of import libraries, lowercasing headers, lowercasing the include directives to match this).
(The WinSDK headers aren't all lowercase, and they're not self-consistent, e.g. a file which uses one CamelCase spelling on disk in the directory is included with a different CamelCase spelling in other headers.)
This is done for a number of reasons; prior to MSVC 2019 (I've been using the basis of these scripts since way before opensourcing them), /showincludes used to produce incorrect case in some cases, so for the dependency files to work with a case sensitive tool, it was best to use all-lowercase paths to headers and such. I don't remember offhand exactly what other reasons we still have for doing the lowercasing (I should recheck and add comments in the script explaining why).
One reason why I would want to keep that lowercasing even if it isn't strictly required with MSVC, is that if compiling things with clang-cl as a native tool, not wrapped in wine, the case inconsistencies in the WinSDK headers do matter. So therefore, I'd probably stick with lowercasing them still. (I could consider an option to install.sh to stop doing such things, if that'd be desired though.)
You're installing MSVC within WSL using these scripts, and then execute cl.exe without using wine?
Yes. The problem is specifically about not finding properly cased DLL filenames during cl.exe invocation. For example, vcruntime140.dll instead of the required VCRUNTIME140.dll. As I understand, you are not lowercasing DLLs. There must be some other tool that screws up the naming, most likely msiextract.
You're installing MSVC within WSL using these scripts, and then execute cl.exe without using wine?
Yes. The problem is specifically about not finding properly cased DLL filenames during
cl.exeinvocation. For example, vcruntime140.dll instead of the required VCRUNTIME140.dll. As I understand, you are not lowercasing DLLs. There must be some other tool that screws up the naming, most likely msiextract.
Please elaborate further. When you try to invoke cl.exe, it fails because it tries to load VCRUNTIME140.dll which doesn't exist, but a lowercased vcruntime140.dll does exist? Wouldn't this only matter once running the pure native Windows executable (which runs as a regular Windows process despite being launched by WSL), where case insensitivity would handle it?
I double-checked against an ordinary Windows Visual Studio installation, and the corresponding file is also lowercase vcruntime140.dll. Indeed, the problem appears to be WSL-specific.