mstorsjo / msvc-wine Goto Github PK

Even with docker installed, the docker build method didn't work for me so I use the method with vsdownload.py and install.sh.

I noticed, the .exe files copied to x64 are the same as x86 in the bin folder.

Output from cl.exe

> cd /opt/msvc/bin/x64
> ./cl
Microsoft (R) C/C++ Optimizing Compiler Version 19.27.29112 for x86
Copyright (C) Microsoft Corporation.  All rights reserved.

usage: cl [ option... ] filename... [ /link linkoption... ]

That cl.exe should have been copied from Hostx64/x64.

I hope this mistake didn't affect the other folders.
I've check the arm and arm64 folders and they had the correct cl.exe.

I created the docker image using your tool the other day, and am running into an issue where I can not get link.exe to run in wine without crashing.
It always comes up with a "Unhandled exception: page fault on write access" when ever cmake calls it. calling link byitself will print the syntax and not cause an error, but as soon as it tries to do something it crashes.
I also tried using the 32bit version of link and had the same problem.
The versions it downloaded were
MSVCVER=14.27.29110
SDKVER=10.0.18362.0

Do you have an ideas what could be happening and what I could do to fix it?

Thanks.

Hi @mstorsjo ,

On Ubuntu 20.04 wine is no longer able to execute 64-bit Windows apps. In order to get it to work, I needed to call wine64 instead of wine explicitly. The change to the script could be like this:

Small fix to the Martin's original scripts: wine64 should be used for x64.
RUN sed -i "s/wine /win64 /" /opt/msvc/bin/x64/wine-msvc.sh

Thanks！you are so great。(c)

I noticed issues when trying to include libraries that are on the $LIB path. A simple example is as follows using the docker image provided (and some additional parts from Dockerfile.clang to have hello.c and clang installed [although I am using clang-cl-10 and not 14 like in that image]):

export BIN=/opt/msvc/bin/x64
export PATH="$BIN:$PATH"

/opt/msvc/msvcenv-native.sh
echo $LIB  # /opt/msvc/vc/tools/msvc/14.37.32822/lib/x64;/opt/msvc/kits/10/lib/10.0.22621.0/ucrt/x64;/opt/msvc/kits/10/lib/10.0.22621.0/um/x64

clang-cl hello.c -o test.exe kernel32.lib  # clang: error: no such file or directory: 'kernel32.lib'

export LIB="$(echo "$LIB" | sed 's/;/:/g')"
echo "$LIB"  # /opt/msvc/vc/tools/msvc/14.37.32822/lib/x64:/opt/msvc/kits/10/lib/10.0.22621.0/ucrt/x64:/opt/msvc/kits/10/lib/10.0.22621.0/um/x64

clang-cl hello.c -o test.exe kernel32.lib  # compiles just fine

I know that in this case, kernel32.lib isn't actually needed, but it is just to show that the lib cannot be found unless : is used in $LIB.

I do not know if this is version-specific, e.g. maybe this happens with clang-cl-10 but not clang-cl-14 or maybe only with certain versions of the MSVC library. If all versions require : then it is an easy fix (just add | sed 's/;/:/g' into msvcenv-native.sh where you are already processing the environmental variables). If not, it will require being much more clever...

CMake's dependency scanning for MSVC involves it passing the /showIncludes flag to cl, which results in it printing

Note: including file: \opt\msvc\vc\tools\msvc\14.29.30133\include\string
Note: including file:  \opt\msvc\vc\tools\msvc\14.29.30133\include\yvals_core.h
Note: including file:   \opt\msvc\vc\tools\msvc\14.29.30133\include\vcruntime.h

etc. to stdout. Unfortunately the backslashes confuse it, meaning that it ends up recompiling the whole project every time.

Changing the third line of /opt/msvc/bin/x64/cl to

$(dirname $0)/wine-msvc.sh $BINDIR/cl.exe "$@" | sed "s/\\\\/\//g" -

fixes this, but it's not a very elegant way of doing it. It probably should say "for every line beginning 'Note: including file:', replace backslashes with slashes" - however you express that in sed.

• resource.h: empty file
• embed.rc: #include "resource.h"
• main.cpp: int main() {}
• CMakeLists.txt:

cmake_minimum_required(VERSION 3.25)
project(rctest)
add_executable(rctest main.cpp embed.rc)

On Windows, touching resource.h and execute ninja -d explain -d keepdepfile -v -j1, RC file is correctly rebuilt.

ninja explain: output CMakeFiles/rctest.dir/embed.rc.res older than most recent input C:/Users/huangqinjin/Projects/rctest/resource.h (7031986049877757 vs 7031986466060779)
ninja explain: CMakeFiles/rctest.dir/embed.rc.res is dirty
ninja explain: rctest.exe is dirty
[1/2] C:/PROGRA~1/CMake/bin/cmcldeps.exe RC C:\Users\huangqinjin\Projects\rctest\embed.rc CMakeFiles\rctest.dir\embed.rc.res.d CMakeFiles\rctest.dir\embed.rc.res "Note: including file: " "C:/Program Files/Microsoft Visual Studio/2022/Enterprise/VC/Tools/MSVC/14.35.32215/bin/Hostx64/x64/cl.exe" C:\PROGRA~2\WI3CF2~1\10\bin\100226~1.0\x64\rc.exe   -DWIN32 -D_DEBUG /fo CMakeFiles\rctest.dir\embed.rc.res C:\Users\huangqinjin\Projects\rctest\embed.rc
[2/2] cmd.exe /C "cd . && "C:\Program Files\CMake\bin\cmake.exe" -E vs_link_exe --intdir=CMakeFiles\rctest.dir --rc=C:\PROGRA~2\WI3CF2~1\10\bin\100226~1.0\x64\rc.exe --mt=C:\PROGRA~2\WI3CF2~1\10\bin\100226~1.0\x64\mt.exe --manifests  -- C:\PROGRA~1\MIB055~1\2022\ENTERP~1\VC\Tools\MSVC\1435~1.322\bin\Hostx64\x64\link.exe /nologo CMakeFiles\rctest.dir\main.cpp.obj CMakeFiles\rctest.dir\embed.rc.res  /out:rctest.exe /implib:rctest.lib /pdb:rctest.pdb /version:0.0 /machine:x64 /debug /INCREMENTAL /subsystem:console  kernel32.lib user32.lib gdi32.lib winspool.lib shell32.lib ole32.lib oleaut32.lib uuid.lib comdlg32.lib advapi32.lib && cd ."

cmcldeps.exe generates depfile for embed.rc:

CMakeFiles\\rctest.dir\\embed.rc.res: \
C:\\Users\\huangqinjin\\Projects\\rctest\\resource.h \

But using msvc-wine on Linux, no depfile for embed.rc is generated. It is due to CMAKE_NINJA_CMCLDEPS_RC is only defined on Windows.
https://gitlab.kitware.com/cmake/cmake/-/blob/0b552eb877b887638e8130bb6c982106a76827d8/Modules/Platform/Windows-MSVC.cmake#L511

Also see related #22.

If the folder name begins, for example, with "t", then after replacing forward slashes with backslashes, the next sed call causes an error. Apparently \t converts to TAB?

For example: /home/a/tools/msvc
Renaming the folder from tools to dtools solves the problem.

sed: -e expression #1, char 37: unterminated `s' command

macOS uses a case-insensitive filesystem.

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?

I'd like to figure out how to install MSBuild - even when manually specifying it, it seems to be skipped.

And thanks for this project!

CC @huangqinjin

Since the introduction of the msvctricks.exe binary, closing the output pipe of the compiler causes hangs.

To reproduce:

$ echo '#include <vector>' > file.cpp
$ cl -E file.cpp | less

Within less, type q to stop reading the input (after only consuming a screenful of output, from the preprocessing output which is large enough to block the pipe buffers). Normally I would expect all processes to exit at this point (possibly with some complaints due to the broken pipe). With msvctricks.exe in place, I instead get a hang. If I remove msvctricks.exe so that this only uses the redirections done in wine-msvc.sh, this works as expected.

Is it possible to add a flag to download headers for things like ATL and MFC?

All other tests run fine, but CMake tests fail for me with the following errors when testing cl:

CMake Error at /usr/share/cmake/Modules/CMakeTestCCompiler.cmake:67 (message):
  The C compiler

    "/opt/msvc/bin/x64/cl"

  is not able to compile a simple test program.

  It fails with the following output:

    Change Dir: '/tmp/msvc-wine.tmp.6V7a/CMakeFiles/CMakeScratch/TryCompile-OjINNN'
    
    Run Build Command(s): /usr/lib/ninja-build/bin/ninja -v cmTC_0d80c
    [1/2] /opt/msvc/bin/x64/cl  /nologo   /DWIN32 /D_WINDOWS  /Ob0 /Od /RTC1 -MDd -Zi /showIncludes /FoCMakeFiles/cmTC_0d80c.dir/testCCompiler.c.obj /FdCMakeFiles/cmTC_0d80c.dir/ /FS -c /tmp/msvc-wine.tmp.6V7a/CMakeFiles/CMakeScratch/TryCompile-OjINNN/testCCompiler.c
    FAILED: CMakeFiles/cmTC_0d80c.dir/testCCompiler.c.obj 
    /opt/msvc/bin/x64/cl  /nologo   /DWIN32 /D_WINDOWS  /Ob0 /Od /RTC1 -MDd -Zi /showIncludes /FoCMakeFiles/cmTC_0d80c.dir/testCCompiler.c.obj /FdCMakeFiles/cmTC_0d80c.dir/ /FS -c /tmp/msvc-wine.tmp.6V7a/CMakeFiles/CMakeScratch/TryCompile-OjINNN/testCCompiler.c
    z:/tmp/msvc-wine.tmp.6V7a/CMakeFiles/CMakeScratch/TryCompile-OjINNN/testCCompiler.c: fatal error C1902: Program database manager mismatch; please check your installation
    ninja: build stopped: subcommand failed.
    
    

  

  CMake will not be able to correctly generate this project.
Call Stack (most recent call first):
  CMakeLists.txt:2 (project)

All SDK files are lowercased after installaiton.

CMake/Ninja uses output of /showIncludes for dependency information.

Currently Ninja keep recompiling when the source code contains uppercase header files, as those files are not exist actually (checked with ninja -d explain).

E.g. most commonly used

#include <Windows.h>
#include <GL/gl.h>

Results in the following error:

Microsoft (R) C/C++ Optimizing Compiler Version 19.36.32535 for x64
Copyright (C) Microsoft Corporation.  All rights reserved.

cl : Command line error D8037 : cannot create temporary il file; clean temp directory of old il files

Not really an issue for me, since I just used the Wine from Debian repos, and that apparently just solved it. So leaving that in here if anyone else runs into the same issue...

Also, if using Debian 12 and installing wine64, the executable wine64 is installed to /usr/lib/wine, which is not in PATH. So someone writing a Dockerfile needs to either manually add it to path, or do ln -s /usr/lib/wine/wine64 /usr/bin/wine64.

Now this is a thing that could be theoretically fixed here by the project, because I think that wine64 is equivalent to WINEARCH=win64 wine, and also wine should be in path. Either that, or to add some path detection perhaps? If Ubuntu bases their packages on Debian, then it might eventually became an issue on it as well.

The file https://github.com/mstorsjo/msvc-wine/blob/master/wrappers/msvcenv.sh and Dockerfile.hello for example points often to /opt/msvc2017/ as the root path of the installation yet the script installs everything at /opt/msvc/

Thanks for this, very cool!

Do you know of any way to get the kernel-mode headers as well? There should be a km directory, alongside um and shared, containing ntifs.h and the like (i.e. what's in /usr/include/ddk for mingw). I had a brief look in Microsoft's package listing but couldn't see anything obvious.

Background

ccache has three working modes:

• The preprocessor mode: Run preprocessor and parse the output file. It is slow.
• The direct mode: Fallback to preprocessor mode if it is not available. It is fast.
• The depend mode. Same as direct mode, but never fallback to preprocessor mode, and rely on outputs of /showIncludes.

Problem

touch /tmp/header.h
echo '#include "header.h"' > /tmp/main.c
CCACHE_LOGFILE=ccache.log CCACHE_NODEPEND= CCACHE_DIRECT= ccache /opt/msvc/bin/x64/cl.exe -c /tmp/main.c
cat ccache.log

] Trying direct lookup
] Manifest key: 74199n1cl3ceh887hu1o509m3thr8mql2
] No 74199n1cl3ceh887hu1o509m3thr8mql2 in local storage
] Running preprocessor
] Executing /opt/msvc/bin/x64/cl.exe -P -Fi/run/user/1000/ccache-tmp/cpp_stdout.tmp.yFZLHy.i /tmp/main.c
] Failed to stat z:/tmp/main.c: No such file or directory
] Disabling direct mode

The direct mode is always disabled due to accessing z:/tmp/main.c.

Cause

The output of /opt/msvc/bin/x64/cl.exe -P /tmp/main.c is the file main.i in CWD if option /Fi is not present.

#line 1 "z:/tmp/main.c"
#line 1 "z:\\tmp\\header.h"
#line 2 "z:/tmp/main.c"

The paths in the file are not converted to unix style. ccache will parse this file and hash the files listed, which is of cause failed, and then direct mode is disabled.

Solution

• Use ccache depend mode. It doesn't run preprocessor but hash files listed in /showIncludes, which we already convert them to unix style paths. OR,
• Postprocess the preprocessor output file: convert to unix style paths. This need implement in wine-msvc.sh wrapper. @mstorsjo What's your opinion?

With my local installation, and with a self-create docker (I haven't tried the official docker):

When I run wineserver -p && cl it hangs forever without giving output.

The underlying issue seems to be that the stdin of the sed/grep pipeline is never disconnected. Even after the wine64 process is gone, the sed and grep procresses are still there and stay there forever. This is very strange, and I don't really how to debug this further but here are some observations:

• In fact, there's output. It's just not printed due to a stdout/stderr buffering issue (and because stdin is never disconnected, the buffer is never flushed). I can get some output by changing the sed to sed -u or grep to grep --line-buffered.
• Another way to get output is to run wineserver -k. Then the pipe is disconnected and the buffers are flushed.
• Also interesting: wineserver -p3 && cl gives output after ~3 seconds (because then the wineserver dies). 3 seconds is the default when the wineserver is started automatically, and from time to time I had already noticed earlier that calling cl is very slow and essentially takes 3 seconds every time. This is probably the issue (even without invoking an explicit wineserver).
• When removing the sed/grep pipeline, the problem just disappears entirely.
• A reliable workaround is to run wineserver -p && wine foo && cl where foo is a (successful) dummy command, e.g. the builtin "hh.exe" is nice because it has no output".

I suspect that somehow the stdin of the pipe is connected to wineserver but I have no idea why this happens. The only thing I could find is this >20 years old thread about a similar issue https://marc.info/?l=wine-devel&m=96644429309991&w=2 But yeah, it's >20 years old...

Hi mstorsjo
Thank you very much for sharing this project ,my local compilation has the following errors. Did I succeed or fail?

Hello,

After running the container, I attempted to compile a simple test hello world program, however I seem to get an error during the build:

# /opt/msvc/bin/x64/cl test.c
Microsoft (R) C/C++ Optimizing Compiler Version 19.29.30133 for x64
Copyright (C) Microsoft Corporation.  All rights reserved.

test.c
Microsoft (R) Incremental Linker Version 14.29.30133.0
Copyright (C) Microsoft Corporation.  All rights reserved.

\opt\msvc\vc\tools\msvc\14.29.30133\bin\Hostx64\x64\link.exe 
/out:test.exe 
test.obj 
\opt\msvc\vc\tools\msvc\14.29.30133\bin\Hostx64\x64\link.exe : fatal error LNK1107: invalid or corrupt file: cannot read at 0x2F8

The issue seems to be in the linker, as if I try to complete the link on a windows VM, it succeeds and I get a working exe, so the compiled obj file seems to be fine.

python3 . /vsdownload.py --dest . /my-msvc

I ran the above command and got an error.
The environment is Ubuntu 20.04.

Extracting Kits Configuration Installer-x86_en-us.msi
Traceback (most recent call last):
  File "./vsdownload.py", line 619, in <module>
    extractPackages(selected, cache, unpack)
  File "./vsdownload.py", line 531, in extractPackages
    unpackWin10SDK(dir, p["payloads"], dest)
  File "./vsdownload.py", line 515, in unpackWin10SDK
    subprocess.check_call(["msiextract", "-C", dest, srcfile], stdout=log)
  File "/usr/lib/python3.8/subprocess.py", line 359, in check_call
    retcode = call(*popenargs, **kwargs)
  File "/usr/lib/python3.8/subprocess.py", line 340, in call
    with Popen(*popenargs, **kwargs) as p:
  File "/usr/lib/python3.8/subprocess.py", line 858, in __init__
    self._execute_child(args, executable, preexec_fn, close_fds,
  File "/usr/lib/python3.8/subprocess.py", line 1704, in _execute_child
    raise child_exception_type(errno_num, err_msg, err_filename)
FileNotFoundError: [Errno 2] No such file or directory: 'msiextract'

Feel free to take some of the stuff I made here if you'd like:
https://github.com/boberfly/docker-msvc-wine

I was able to find a way to get MSVC and SDK without needing to zip up an installed version from a Windows machine. Unfortunately it is limited to a specific old version hosted on Nuget, but the SDK should be recent.

Cheers

According to the description from Ubuntu, the Ubuntu 19.04 docker image is no longer officially support. As a result, the apt server is turned down, and a docker image or container cannot use apt to install or upgrade any packages.

This project is also affected since it uses apt commands in the dockerfile so that the build will fail on the unreachable apt server. To solve this problem, you may want to upgrade to version 19.10 or 20.04.

Personally, I would suggest 20.04 because it is a LTS version although it is still in beta.

It would be nice for there to be available insttuctions on how to use with CMake. Currently, there are none, and compiling using the bash wrappers as compilers in cmake with CMAKE_C_COMPILER_WORKS=1 and CMAKE_CXX_COMPILER_WORKS=1 seems to either be very slow, or just plain hangs.

A toolchain file would be much appreciated.

The installer script seems to be tripping up on / skipping msi files ending in .Msi instead of .msi

Also, does this download everything there is about visual studio or only the parts relevant to the C/C++ toolchain? Seems like quite a lot of packages (and yet it doesn't appear as if MSBuild.exe is included, which means .sln / .vcxproj cannot be easily built from the commandline..)

I would like to build msvc-wine VS2017 (--major 15) with specific MSVC toolchain version (--msvc-version 15.9). But vsdownload.py shows me not find the exact version packages for 15.9 and failed to download packages as below.

How can I build the correct msvc-wine docker image for VS2017 and VS2019?

Step 8/9 : RUN PYTHONUNBUFFERED=1 ./vsdownload.py --major 15 --msvc-version 15.9 --accept-license --dest /opt/msvc && ./install.sh /opt/msvc && rm lowercase fixinclude install.sh vsdownload.py && rm -rf wrappers
---> Running in 03961cbca19f
Fetching https://aka.ms/vs/15/release/channel
Got toplevel manifest for 15.9.56
Loaded installer manifest for 15.9.56
Didn't find exact version packages for 15.9, assuming this is provided by the default/latest version
Selected 306 packages, for a total download size of 1.7 GB, install size of 5.5 GB
Downloading Microsoft.VisualStudio.VC.MSBuild.ARM-15.8.27729.1/payload.vsix (6.9 KB)
Downloading Microsoft.VisualStudio.VC.MSBuild.Base-15.9.28307.1063/payload.vsix (306.7 KB)
Downloading Microsoft.VisualStudio.VC.MSBuild.Base.Resources-15.9.28307.1063/payload.vsix (88.1 KB)
Downloading Microsoft.VisualStudio.VC.MSBuild.X64-15.8.27729.1/payload.vsix (7.1 KB)
Downloading Microsoft.VS.VC.MSBuild.X64.Resources-15.0.26621.2/microsoft.visualstudio.vc.msbuild.x64.resources.vsix (1.3 KB)
Downloading Microsoft.VisualStudio.VC.MSBuild.X86-15.8.27729.1/payload.vsix (6.9 KB)
Downloading Microsoft.Windows.UniversalCRT.Redistributable.Msi-10.0.26624/Universal CRT Redistributable-x86_en-us.msi (304.0 KB)
Downloading Microsoft.Windows.UniversalCRT.Redistributable.Msi-10.0.26624/9126f6ff98d955951fe9323f4444c119.cab (445.0 KB)
Downloading Microsoft.Windows.UniversalCRT.Redistributable.Msi-10.0.26624/948a611cd2aca64b1e5113ffb7b95d5f.cab (610.7 KB)
Downloading Microsoft.Windows.UniversalCRT.Redistributable.Msi-10.0.26624/fef2cfedd6135e0ed85290b83f3682c3.cab (589.3 KB)
Downloading Microsoft.VisualCpp.CRT.Headers-14.16.27033/Microsoft.VisualCpp.CRT.Headers.vsix (2.9 MB)
Downloading Microsoft.VisualCpp.Redist.14-14.16.27033.4-x64/VC_redist.x64.exe (14.6 MB)
Downloading Microsoft.VisualCpp.Redist.14-14.16.27033.4-x86/VC_redist.x86.exe (14.0 MB)
Downloading Microsoft.Windows.UniversalCRT.Msu.7-10.0.26624.1-x64/Windows6.1-KB2999226-x64.msu (1.0 MB)
Downloading Microsoft.Windows.UniversalCRT.Msu.8-10.0.26624-x64/Windows8-RT-KB2999226-x64.msu (1.3 MB)
Downloading Microsoft.Windows.UniversalCRT.Msu.81-10.0.26624-x64/Windows8.1-KB2999226-x64.msu (1.0 MB)
Downloading Microsoft.VisualCpp.RuntimeDebug.14-14.16.27033.1-x64/vc_RuntimeDebug.msi (184.0 KB)
Downloading Microsoft.VisualCpp.RuntimeDebug.14-14.16.27033.1-x64/cab1.cab (8.9 MB)
Downloading Microsoft.VisualCpp.RuntimeDebug.14-14.16.27033.1-x86/vc_RuntimeDebug.msi (180.0 KB)
Downloading Microsoft.VisualCpp.RuntimeDebug.14-14.16.27033.1-x86/cab1.cab (8.5 MB)
Downloading Microsoft.VisualCpp.CRT.Redist.X64-14.16.27033.3/Microsoft.VisualCpp.CRT.Redist.X64.vsix (33.6 MB)
Downloading Microsoft.VisualCpp.CRT.Redist.Resources-14.16.27033/Microsoft.VisualCpp.CRT.Redist.Resources.enu.vsix (1.0 KB)
Downloading Microsoft.VisualCpp.CRT.Redist.X86-14.16.27033.3/Microsoft.VisualCpp.CRT.Redist.X86.vsix (31.8 MB)
Downloading Microsoft.VisualCpp.CRT.Source-14.16.27023/Microsoft.VisualCpp.CRT.Source.vsix (1.0 MB)
Downloading Microsoft.VisualCpp.CRT.x64.Desktop-14.16.27032/Microsoft.VisualCpp.CRT.x64.Desktop.vsix (39.8 MB)
Downloading Microsoft.VisualCpp.CRT.x86.Desktop-14.16.27032/Microsoft.VisualCpp.CRT.x86.Desktop.vsix (36.0 MB)
Downloading Microsoft.VisualCpp.DIA.SDK-14.16.27050/Microsoft.VisualCpp.DIA.SDK.vsix (3.7 MB)
Downloading Microsoft.VisualCpp.Tools.Core.x86-14.16.27027/Microsoft.VisualCpp.Tools.Core.x86.vsix (5.6 KB)
Downloading Microsoft.VisualCpp.Tools.Common.Utils-14.16.27027/Microsoft.VisualCpp.Tools.Common.Utils.vsix (75.9 KB)
Downloading Microsoft.VisualCpp.Tools.Common.Utils.Resources-14.16.27027/Microsoft.VisualCpp.Tools.Common.Utils.Resources.enu.vsix (27.3 KB)
Downloading Microsoft.VisualCpp.Tools.Core.Resources-14.16.27027/Microsoft.VisualCpp.Tools.Core.Resources.enu.vsix (1.0 KB)
Downloading Microsoft.VisualCpp.Tools.HostX86.TargetX86-14.16.27050/Microsoft.VisualCpp.Tools.HostX86.TargetX86.vsix (13.5 MB)
Downloading Microsoft.VisualCpp.Tools.HostX86.TargetX86.Resources-14.16.27050/Microsoft.VisualCpp.Tools.HostX86.TargetX86.Resources.enu.vsix (199.1 KB)
Downloading Microsoft.VisualCpp.VCTip.hostX86.targetX86-14.16.27050/Microsoft.VisualCpp.VCTip.hostX86.targetX86.vsix (1.0 KB)
Downloading Microsoft.VisualCpp.Tools.HostX86.TargetX64-14.16.27050/Microsoft.VisualCpp.Tools.HostX86.TargetX64.vsix (9.1 MB)
Downloading Microsoft.VisualCpp.Tools.Hostx86.Targetx64.Resources-14.16.27050/Microsoft.VisualCpp.Tools.Hostx86.Targetx64.Resources.enu.vsix (125.6 KB)
Downloading Microsoft.VisualCpp.VCTip.hostX86.targetX64-14.16.27050/Microsoft.VisualCpp.VCTip.hostX86.targetX64.vsix (1.0 KB)
Downloading Microsoft.VisualCpp.CRT.ClickOnce.Msi-14.16.27033/vcpp_crt.redist.clickonce.msi (180.0 KB)
Downloading Microsoft.VisualCpp.CRT.ClickOnce.Msi-14.16.27033/cab1.cab (18.5 KB)
Downloading Microsoft.VisualCpp.CRT.Redist.x64.OneCore.Desktop-14.16.27033/Microsoft.VisualCpp.CRT.Redist.x64.OneCore.Desktop.vsix (1.5 MB)
ConnectionResetError: [Errno 104] Connection reset by peer
Incorrect existing file Microsoft.VisualCpp.Tools.HostX86.TargetX64-14.16.27050/Microsoft.VisualCpp.Tools.HostX86.TargetX64.vsix, removing
Downloading Microsoft.VisualCpp.Tools.HostX86.TargetX64-14.16.27050/Microsoft.VisualCpp.Tools.HostX86.TargetX64.vsix (9.1 MB)
Downloading Microsoft.VisualCpp.CRT.Redist.x86.OneCore.Desktop-14.16.27033/Microsoft.VisualCpp.CRT.Redist.x86.OneCore.Desktop.vsix (1.3 MB)
Downloading Microsoft.VisualCpp.CRT.x64.OneCore.Desktop-14.16.27023/Microsoft.VisualCpp.CRT.x64.OneCore.Desktop.vsix (48.6 MB)
Downloading Microsoft.VisualCpp.CRT.x64.Store-14.16.27032/Microsoft.VisualCpp.CRT.x64.Store.vsix (9.0 MB)
ConnectionResetError: [Errno 104] Connection reset by peer
Incorrect existing file Microsoft.VisualCpp.Tools.HostX86.TargetX64-14.16.27050/Microsoft.VisualCpp.Tools.HostX86.TargetX64.vsix, removing
Downloading Microsoft.VisualCpp.Tools.HostX86.TargetX64-14.16.27050/Microsoft.VisualCpp.Tools.HostX86.TargetX64.vsix (9.1 MB)
Downloading Microsoft.VisualCpp.CRT.x86.OneCore.Desktop-14.16.27023/Microsoft.VisualCpp.CRT.x86.OneCore.Desktop.vsix (44.3 MB)
Downloading Microsoft.VisualCpp.CRT.x86.Store-14.16.27032/Microsoft.VisualCpp.CRT.x86.Store.vsix (8.7 MB)
ConnectionResetError: [Errno 104] Connection reset by peer
Incorrect existing file Microsoft.VisualCpp.Tools.HostX86.TargetX64-14.16.27050/Microsoft.VisualCpp.Tools.HostX86.TargetX64.vsix, removing
Downloading Microsoft.VisualCpp.Tools.HostX86.TargetX64-14.16.27050/Microsoft.VisualCpp.Tools.HostX86.TargetX64.vsix (9.1 MB)
Downloading Microsoft.VisualCpp.PGO.Headers-14.16.27023/Microsoft.VisualCpp.PGO.Headers.vsix (1.8 KB)
Downloading Microsoft.VisualCpp.PGO.X64-14.16.27023/Microsoft.VisualCpp.PGO.X64.vsix (19.3 KB)
Downloading Microsoft.VisualCpp.PGO.X86-14.16.27023/Microsoft.VisualCpp.PGO.X86.vsix (19.2 KB)
Downloading Microsoft.VisualCpp.Premium.Tools.HostX64.TargetX64-14.16.27023-x64/Microsoft.VisualCpp.Premium.Tools.HostX64.TargetX64.vsix (195.0 KB)
Downloading Microsoft.VisualCpp.Premium.Tools.HostX64.TargetX64.Resources-14.16.27023-x64/Microsoft.VisualCpp.Premium.Tools.HostX64.TargetX64.Resources.enu.vsix (29.4 KB)
Downloading Microsoft.VisualCpp.Premium.Tools.HostX64.TargetX86-14.16.27023-x64/Microsoft.VisualCpp.Premium.Tools.HostX64.TargetX86.vsix (99.9 KB)
Downloading Microsoft.VisualCpp.Premium.Tools.HostX64.TargetX86.Resources-14.16.27023-x64/Microsoft.VisualCpp.Premium.Tools.HostX64.TargetX86.Resources.enu.vsix (16.7 KB)
Downloading Microsoft.VisualCpp.Premium.Tools.HostX86.TargetX86-14.16.27023/Microsoft.VisualCpp.Premium.Tools.HostX86.TargetX86.vsix (178.9 KB)
Downloading Microsoft.VisualCpp.Premium.Tools.HostX86.TargetX86.Resources-14.16.27023/Microsoft.VisualCpp.Premium.Tools.HostX86.TargetX86.Resources.enu.vsix (29.3 KB)
ConnectionResetError: [Errno 104] Connection reset by peer
Incorrect existing file Microsoft.VisualCpp.Tools.HostX86.TargetX64-14.16.27050/Microsoft.VisualCpp.Tools.HostX86.TargetX64.vsix, removing
Downloading Microsoft.VisualCpp.Tools.HostX86.TargetX64-14.16.27050/Microsoft.VisualCpp.Tools.HostX86.TargetX64.vsix (9.1 MB)
Downloading Microsoft.VisualCpp.Premium.Tools.HostX86.TargetX64-14.16.27023/Microsoft.VisualCpp.Premium.Tools.HostX86.TargetX64.vsix (91.1 KB)
Downloading Microsoft.VisualCpp.Premium.Tools.Hostx86.Targetx64.Resources-14.16.27023/Microsoft.VisualCpp.Premium.Tools.Hostx86.Targetx64.Resources.enu.vsix (16.6 KB)
Downloading Microsoft.VisualCpp.Tools.HostX64.TargetX64-14.16.27050-x64/Microsoft.VisualCpp.Tools.HostX64.TargetX64.vsix (15.3 MB)
Downloading Microsoft.VisualCpp.Tools.HostX64.TargetX64.Resources-14.16.27050-x64/Microsoft.VisualCpp.Tools.HostX64.TargetX64.Resources.enu.vsix (199.0 KB)
Downloading Microsoft.VisualCpp.VCTip.HostX64.TargetX64-14.16.27050-x64/Microsoft.VisualCpp.VCTip.HostX64.TargetX64.vsix (1.0 KB)
Downloading Microsoft.VisualCpp.Tools.HostX64.TargetX86-14.16.27050-x64/Microsoft.VisualCpp.Tools.HostX64.TargetX86.vsix (10.6 MB)
Downloading Microsoft.VisualCpp.Tools.HostX64.TargetX86.Resources-14.16.27050-x64/Microsoft.VisualCpp.Tools.HostX64.TargetX86.Resources.enu.vsix (125.6 KB)
multiprocessing.pool.RemoteTraceback:
"""
Traceback (most recent call last):
File "/usr/lib/python3.8/multiprocessing/pool.py", line 125, in worker
result = (True, func(*args, **kwds))
File "./vsdownload.py", line 445, in _downloadPayload
six.moves.urllib.request.urlretrieve(payload["url"], destname)
File "/usr/lib/python3.8/urllib/request.py", line 276, in urlretrieve
block = fp.read(bs)
File "/usr/lib/python3.8/http/client.py", line 459, in read
n = self.readinto(b)
File "/usr/lib/python3.8/http/client.py", line 503, in readinto
n = self.fp.readinto(b)
File "/usr/lib/python3.8/socket.py", line 669, in readinto
return self._sock.recv_into(b)
File "/usr/lib/python3.8/ssl.py", line 1241, in recv_into
return self.read(nbytes, buffer)
File "/usr/lib/python3.8/ssl.py", line 1099, in read
return self._sslobj.read(len, buffer)
ConnectionResetError: [Errno 104] Connection reset by peer
"""

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
File "./vsdownload.py", line 618, in
downloadPackages(selected, cache, allowHashMismatch=args.only_download)
File "./vsdownload.py", line 423, in downloadPackages
downloaded = sum(task.get() for task in tasks)
File "./vsdownload.py", line 423, in
downloaded = sum(task.get() for task in tasks)
File "/usr/lib/python3.8/multiprocessing/pool.py", line 771, in get
raise self._value
ConnectionResetError: [Errno 104] Connection reset by peer
The command '/bin/sh -c PYTHONUNBUFFERED=1 ./vsdownload.py --major 15 --msvc-version 15.9 --accept-license --dest /opt/msvc && ./install.sh /opt/msvc && rm lowercase fixinclude install.sh vsdownload.py && rm -rf wrappers' returned a non-zero code: 1

Is it possible to create CC and CXX wrappers for the MSVC cl compiler with Unix interface (e.g. similar to Clang/LLVM or GCC in Unix) that wraps around Unix interface flags to the matching ones in cl, so it can be used in Autoconf based projects?

Could you please update it to CMake 3.22 by rebasing it onto cmake's release branch?

caused:

005a:err:winediag:SECUR32_initNTLMSP ntlm_auth was not found or is outdated. Make sure that ntlm_auth >= 3.0.25 is in your path. Usually, you can find it in the winbind package of your distribution.

additional package required:

sudo apt install winbind

Hello @mstorsjo,

I was trying to build a C/C++ project a while ago (not sure whether it was ZLib or LLVM, but pretty sure it was a CMake-based project), and CMake was failing on mt.exe. However, if mt.exe ran again after failing the first time, CMake would pass.

I was about to make the following change to the script, but was hesitant whether or not this is a hacky fix:

diff --git a/wrappers/mt b/wrappers/mt
index 30349ed..f6f359f 100755
--- a/wrappers/mt
+++ b/wrappers/mt
@@ -1,3 +1,7 @@
 #!/bin/bash
 . $(dirname $0)/msvcenv.sh
 $(dirname $0)/wine-msvc.sh $SDKBINDIR/mt.exe "$@"
+
+if [ $? -ne 0 ]; then
+    $(dirname $0)/wine-msvc.sh $SDKBINDIR/mt.exe "$@"
+fi

I see that vsdownload.py has a license inline (ISC?) but the other code has not. Are you willing and would you mind adding a LICENSE or LICENSE.txt?

And thanks, this project is very useful. I use it to test code on MSVC without having to resort to a Windows machine.

The VCTIP executable is bugged and can cause cl.exe to hang. Removing it seems to have no adverse effects and fixes the hang. Please remove all VCTIP.exe instances during the installation process as per https://bugs.chromium.org/p/chromium/issues/detail?id=735226

Repro

main.cpp

#include <stdio.h>

without /scanDependencies

$ /opt/msvc/bin/x64/cl.exe /c main.cpp /showIncludes
Microsoft (R) C/C++ Optimizing Compiler Version 19.36.32502 for x64
Copyright (C) Microsoft Corporation.  All rights reserved.

main.cpp
Note: including file: /opt/msvc/kits/10/include/10.0.22621.0/ucrt/stdio.h
Note: including file:  /opt/msvc/kits/10/include/10.0.22621.0/ucrt/corecrt.h
Note: including file:   /opt/msvc/vc/tools/msvc/14.36.32502/include/vcruntime.h
Note: including file:    /opt/msvc/vc/tools/msvc/14.36.32502/include/sal.h
Note: including file:     /opt/msvc/vc/tools/msvc/14.36.32502/include/concurrencysal.h
Note: including file:    /opt/msvc/vc/tools/msvc/14.36.32502/include/vadefs.h
Note: including file:  /opt/msvc/kits/10/include/10.0.22621.0/ucrt/corecrt_wstdio.h
Note: including file:   /opt/msvc/kits/10/include/10.0.22621.0/ucrt/corecrt_stdio_config.h

with /scanDependencies

$ /opt/msvc/bin/x64/cl.exe /c main.cpp /showIncludes /scanDependencies main.cpp.obj.ddi
Microsoft (R) C/C++ Optimizing Compiler Version 19.36.32502 for x64
Copyright (C) Microsoft Corporation.  All rights reserved.

main.cpp
Note: including file: z:\opt\msvc\kits\10\include\10.0.22621.0\ucrt\stdio.h
Note: including file:  z:\opt\msvc\kits\10\include\10.0.22621.0\ucrt\corecrt.h
Note: including file:   z:\opt\msvc\vc\tools\msvc\14.36.32502\include\vcruntime.h
Note: including file:    z:\opt\msvc\vc\tools\msvc\14.36.32502\include\sal.h
Note: including file:     z:\opt\msvc\vc\tools\msvc\14.36.32502\include\concurrencysal.h
Note: including file:    z:\opt\msvc\vc\tools\msvc\14.36.32502\include\vadefs.h
Note: including file:  z:\opt\msvc\kits\10\include\10.0.22621.0\ucrt\corecrt_wstdio.h
Note: including file:   z:\opt\msvc\kits\10\include\10.0.22621.0\ucrt\corecrt_stdio_config.h

Additional Information

Seems if /scanDependencies is not specified, /showIncludes output to stdout, otherwise /showIncludes output to stderr.

Hey, I have discovered some problem with /FI Compiler Option. When it is being used, compiler fails to build a project, while same project without it is built fine.

Steps to reproduce:

1. Get a compiliable project.
2. Add using of /FI Compiler Option (target_precompiled_headers for example in CMake).

CMake log example:

[5/9] Building CXX object CMake...ox_runner.dir/cmake_pch.cxx.obj
FAILED: CMakeFiles/sandbox_runner.dir/cmake_pch.cxx.obj 
/opt/msvc/bin/x64/cl  /nologo /TP  -I../service/include -I../ioctl/include /DWIN32 /D_WINDOWS /GR /EHsc /O1 /Ob1 /DNDEBUG -MT   -std:c++17 /Yc/src/build/CMakeFiles/sandbox_runner.dir/cmake_pch.hxx /Fp/src/build/CMakeFiles/sandbox_runner.dir/cmake_pch.cxx.pch /FI/src/build/CMakeFiles/sandbox_runner.dir/cmake_pch.hxx /showIncludes /FoCMakeFiles/sandbox_runner.dir/cmake_pch.cxx.obj /FdCMakeFiles/sandbox_runner.dir/ /FS -c CMakeFiles/sandbox_runner.dir/cmake_pch.cxx
cl : Command line error D8004 : '/FI' requires an argument
[6/9] Linking CXX static library service/service.lib
ninja: build stopped: subcommand failed.

May be someone has faced that issue and has found solution.

Thanks in advance.

I have problem with running install.sh with path as destination.

The README shows that a custom version CMake 844ccd2280d11ada286d0e2547c0fa5ff22bd4db is needed. That version has 4 commit on top of official CMake.

• Don't set CMAKE_NINJA_CMCLDEPS_RC=1 if cross compiling.
  This commit is already upstreamed and is avaliable since CMake 3.23.

• Define _ARM_WINAPI_PARTITION_DESKTOP_SDK_AVAILABLE=1 when building for arm
  I believe this is avaliable since Windows 10 October 2018 Update.
  huangqinjin/ucrt@10.0.17134.0...10.0.17763.0#diff-783e189238639bd1391011cae2be302cf6da473b146e7dc59b3c7edc306d33f4R242-R244

• Use /Z7 instead of /Zi, which doesn't work in wine
  Since CMake 3.25, we can use the new CMake variable for the same purpose. BTW, @mstorsjo any known reason can share why it is needed? Edit: Zi is supported, see below discussion and PR #65.

  set(CMAKE_MSVC_DEBUG_INFORMATION_FORMAT "$<$<CONFIG:Debug,RelWithDebInfo>:Embedded>")

• Don't use notify_update with mt.exe
  This is still needed (why). @mstorsjo are you interested in a PR that strip out /notify_update from mt wrapper script, such that we can use the official CMake? Edit: /notify_update is supported, see PR #63.

This is a CMakePresets.json expected to work after mt.exe issue fixed PR #63 and #65.

{
  "version": 3,
  "cmakeMinimumRequired": {
    "major": 3,
    "minor": 23,
    "patch": 0
  },
  "configurePresets": [
    {
      "name": "msvc-wine",
      "generator": "Ninja",
      "cacheVariables": {
        "CMAKE_C_COMPILER": "/opt/msvc/bin/x64/cl.exe",
        "CMAKE_CXX_COMPILER": "/opt/msvc/bin/x64/cl.exe",
        "CMAKE_RC_COMPILER": "/opt/msvc/bin/x64/rc.exe",
        "CMAKE_SYSTEM_NAME": "Windows",
        "CMAKE_SYSTEM_VERSION": "10",
        "CMAKE_CROSSCOMPILING_EMULATOR": "env;WINEDEBUG=-all;wine64",
        "CMAKE_BUILD_TYPE": "RelWithDebInfo"
      },
      "condition": {
        "string": "${hostSystemName}",
        "type": "notInList",
        "list" : [ "Windows" ]
      }
    }
  ]
}

The code that I am trying to get to compile currently imports a type library:

#import "Library/lib/ActiveSkin.ocx" raw_interfaces_only, raw_native_types, no_namespace, named_guids

However, when compiling I get the following:

fatal error C1083: Cannot open compiler generated file: '[PROJECT]\cmake-build-release-wine_msvc\CMakeFiles\project.dir\activeskin.tlh': Permission denied

Is this supported?

In MSVC RC there is an issue with unfiltered command prefix. As the issue seems to be rather CMake/Ninja-specific, I have filled it there: https://gitlab.kitware.com/cmake/cmake/-/issues/21760

E.g. VC/Tools/MSVC/14.36.32530/include/comdef.h includes Ole2.h and OleCtl.h.

Hi,

Thank you so much for that. It will be such a relief to stop switching to windows just to test the MSVC hacks.

CMake has been working fine and building that simple program mentioned in the README.md.

Then I get this weird

0214:err:msvcrt:read_i got odd number of bytes in UTF16 mode

error.

Here is the complete output for the library I'm trying to build, just in case.

Do people go through that very often?

I'm really a noob here, so this might be a stupid issue.

In the tool wrappers, there are two sources of WINEPATH enviroment variables, but both may cause problems:

1. For nmake, the WINEPATH comes from BINDIR.
   To my understanding, SDKBINDIR should also be included. Otherwise, nmake cannot correctly find rc. You can try to compile putty to regenerate an error that complains about missing rc.

2. For other wrappers, the WINEPATH is exported in msvcenv.sh and is set to $MSVCDIR\bin\Hostx64\x64
   This directory is fixed to Hostx64\x64 regardless of which arch we are targeting. To the best of my knowledge, the folder should depend on the target arch, and it is better to use original directories (SDKBINDIR and BINDIR) instead of the wrapper directories in case that some other exes and dlls are required.

When trying the "Use with Clang/LLD in MSVC mode" approach, I'm getting warnings and errors like this:

clang-14: warning: unable to find a Visual Studio installation; try running Clang from a developer command prompt [-Wmsvc-not-found]
test.cpp(1,10): fatal error: 'iostream' file not found
#include <iostream>
         ^~~~~~~~~~
1 error generated.

I'm guessing that msvc-not-found warning is related to the error, because clang might get these standard library files from the visual studio installation.

Are the standard libraries like iostream supposed to be provided by msvc or do I have to use mingw's libraries?

*.exe in wrappers are symlinks, but they are installed by plain cp command, and thoses symlinks are resolved to normal files. Is it intentional? It not, cp -a should be used.

I'm probably doing something very wrong, but concrt seems to be missed by lowercase? (vc/tools/msvc/14.32.31326/crt/src/concrt/)

(specofically, Platform.h)

LLVM DIA SDK support seems to need the ATL package ("Microsoft.VisualStudio.Component.VC.ATL"). Add it to the default package since DIA SDK is included already?

https://github.com/llvm/llvm-project/blob/7ee1c162cc53d37f717f9a138276ad64fa6863bc/llvm/include/llvm/DebugInfo/PDB/DIA/DIASupport.h#L25