Trouble getting setup on Windows

Development Windows
1

I'm trying to figure out the current guidelines for getting Swift working on Windows. My attempt is using the Swift 5.5.1 installer. I am on Windows 11, FWIW.

The basic symptom here is that I cd into an empty directory and do:

swift package init
swift build

and I get

error: manifest parse error(s):
<unknown>:0: error: missing required module 'ucrt'

Which seems to suggest that I don't have the necessary Visual Studio components installed, but I think I do.

I have Visual Studio 2019 Enterprise. I've got both of these installed:

  --add Microsoft.VisualStudio.Component.Windows10SDK.19041
  --add Microsoft.VisualStudio.Component.VC.Tools.x86.x64

Interestingly, when I try the swift build from a Visual Studio command prompt (x64 Native tools) I get the error above (missing required module 'ucrt'), but if I try it from a regular command prompt, I get:

error: manifest parse error(s):
<module-includes>:1:10: note: in file included from <module-includes>:1:
#include "AssertionReporting.h"
         ^
C:\Library\Developer\Platforms\Windows.platform\Developer\SDKs\Windows.sdk\usr\lib\swift\shims\AssertionReporting.h:16:10: note: in file included from C:\Library\Developer\Platforms\Windows.platform\Developer\SDKs\Windows.sdk\usr\lib\swift\shims\AssertionReporting.h:16:
#include "SwiftStdint.h"
         ^
C:\Library\Developer\Platforms\Windows.platform\Developer\SDKs\Windows.sdk\usr\lib\swift\shims\SwiftStdint.h:28:10: error: 'stdint.h' file not found
#include <stdint.h>
         ^
<unknown>:0: error: could not build C module 'SwiftShims'

I wasn't sure if maybe swift requires VS 2019 Community (rather than Enterprise), so I tried that installing that as well, but no luck.

I've tried running the Swift installer by downloading it and running it manually. I've also tried the winget-oriented instructions on the download page.

The instructions on the download page seem to suggest that doing the "Support files" stuff to copy the modulemap files should no longer be necessary for Swift 5.5.1, but given the nature of the error messages, I am wondering about that.

Can anyone clarify what steps should be necessary to get swift tools going on Windows?

Thanks!

1 Like
2

That does look like you are missing the modules. I assume that you installed Swift after VS? The installer should have copied the modules into place. I wonder if you didn't give the installer administrator rights? If you did, could you uninstall Swift, and then run the installer again with -log ... to get the log of what is going on during the installer?

If you installed Swift before Visual Studio, then you should just be able to use the repair from the installer to have it deploy it.

1 Like
3

Thanks for the reply. Very helpful.

I was unsure of the ordering, as I had tried several different combinations, so I uninstalled swift and tried it again. Same error, but then I ran with the -log option you suggested, and that revealed the issue.

I had some symlinks left over from a time several months ago when I was trying to build the Windows swift compiler myself. Those symlinks were preventing the ucrt and um modulemap files from getting copied into place. I removed the symlinks, ran the installer with repair, and then it worked.

Bottom line: This was (kinda/mostly) my fault for not realizing I had not fully cleaned up the old stuff.

Thanks again!

4

Ah, thanks. Interesting; the std::filesystem::copy_file does use std::filesystem::copy_options::overwrite_existing. I wonder if there is something else that needs to be done to handle this?

I suppose that it is possible to try to explicitly use remove_file, but would be good to understand why it doesn't work as expected.

5

I assume it has sometime to do with the symlink. Specifically, it was a symlink to a place that no longer existed. So perhaps the copy_file tried to follow the symlink instead of overwrite it, and in doing so, it referenced a directory that was not found, so it failed. Just a guess.

6

The error message in the logs might be helpful in tracking down that behaviour - ec.message should hopefully give us the information.

7

I don't know what ec.message is. :frowning:

When I ran the installer with --log foo, I got several log files in the same directory. One of them is called foo_001_sdk.msi.log and it contains a few things that look relevant. I don't see an attach option in this forum, and I don't want to blast the whole file into here, so I'll paste in some snippets:

There's this:

ucrt.modulemap,SourceCabKey=UCRT_MODULEMAP,DestName=ucrt.modulemap,Attributes=1536,FileSize=2590,PerTick=65536,,VerifyMedia=1,,,,,CheckCRC=0,,,InstallMode=61341696,HashOptions=0,HashPart1=-1607554722,HashPart2=-881006669,HashPart3=166541103,HashPart4=-1954800470,,)
MSI (s) (9C:F0) [18:57:55:472]: File: C:\Library\Developer\Platforms\Windows.platform\Developer\SDKs\Windows.sdk\usr\share\ucrt.modulemap;	Overwrite;	Won't patch;	Existing file is unversioned and unmodified - hash matches source file
MSI (s) (9C:F0) [18:57:55:472]: Source for file 'UCRT_MODULEMAP' is compressed
MSI (s) (9C:F0) [18:57:55:472]: Re-applying security from existing file.
MSI (s) (9C:F0) [18:57:55:472]: Verifying accessibility of file: ucrt.modulemap
MSI (s) (9C:F0) [18:57:55:472]: Note: 1: 2318 2:  
MSI (s) (9C:F0) [18:57:55:472]: Note: 1: 2318 2:

and this:

MSI (s) (9C:F4) [18:57:55:567]: Hello, I'm your 32bit Elevated Non-remapped custom action server.
[6472:8440:1119/185755.567:INFO:swift_installer.cc(294)] SDKROOT: C:\Library\Developer\Platforms\Windows.platform\Developer\SDKs\Windows.sdk
[6472:8440:1119/185755.583:INFO:swift_installer.cc(298)] UniversalCRTSdkDir: "C:\\Program Files (x86)\\Windows Kits\\10\\"
[6472:8440:1119/185755.583:INFO:swift_installer.cc(329)] Deployed "C:\\Program Files (x86)\\Windows Kits\\10\\Include\\10.0.16299.0\\ucrt\\module.modulemap"
[6472:8440:1119/185755.583:INFO:swift_installer.cc(329)] Deployed "C:\\Program Files (x86)\\Windows Kits\\10\\Include\\10.0.16299.0\\um\\module.modulemap"
[6472:8440:1119/185755.583:INFO:swift_installer.cc(329)] Deployed "C:\\Program Files (x86)\\Windows Kits\\10\\Include\\10.0.17763.0\\ucrt\\module.modulemap"
[6472:8440:1119/185755.583:INFO:swift_installer.cc(329)] Deployed "C:\\Program Files (x86)\\Windows Kits\\10\\Include\\10.0.17763.0\\um\\module.modulemap"
[6472:8440:1119/185755.583:INFO:swift_installer.cc(329)] Deployed "C:\\Program Files (x86)\\Windows Kits\\10\\Include\\10.0.18362.0\\ucrt\\module.modulemap"
[6472:8440:1119/185755.583:INFO:swift_installer.cc(329)] Deployed "C:\\Program Files (x86)\\Windows Kits\\10\\Include\\10.0.18362.0\\um\\module.modulemap"
[6472:8440:1119/185755.583:ERROR:swift_installer.cc(324)] unable to copy "C:\\Library\\Developer\\Platforms\\Windows.platform\\Developer\\SDKs\\Windows.sdk\\usr\\share\\ucrt.modulemap" to "C:\\Program Files (x86)\\Windows Kits\\10\\Include\\10.0.19041.0\\ucrt\\module.modulemap": The system cannot find the path specified.
[6472:8440:1119/185755.583:ERROR:swift_installer.cc(324)] unable to copy "C:\\Library\\Developer\\Platforms\\Windows.platform\\Developer\\SDKs\\Windows.sdk\\usr\\share\\winsdk.modulemap" to "C:\\Program Files (x86)\\Windows Kits\\10\\Include\\10.0.19041.0\\um\\module.modulemap": The system cannot find the path specified.
8

I think that you may be right and its trying to copy the file to the destination? That sounds like a bug in the implementation of std::filesystem::copy_file or my usage (of options) is incorrect.

9

I am not too familiar with that C++ API, but I suppose it all depends on its documented behavior for symlinks.

This page (which I found with just a quick google search) says a thing or two that might be relevant:

https://en.cppreference.com/w/cpp/filesystem/copy_file

including the words "filesystem::copy_file follows symlinks"

but this is clearly not Windows-specific content, and I tend to interpret everything about symlinks on Windows as tentative and subject to verification.

With a bit more pessimism than is perhaps warranted, I wonder if you need to check to see if the destination is present AND if it happens to be a symlink AND if so remove it using a possibly-special call that is known to remove the symlink itself instead of follow it.

10

Thanks for the additional information about what exactly was happening.

If the destination file already exists and is a symbolic link, the target of the symbolic link is overwritten by the source file.

Okay; seems that the overwrite existing is a liability. The only problem is that I don't see a good way to handle this without a race condition and I'd prefer to not do something particularly complicated (I suppose that I can do a copy to a temp name to ensure that the file is on the same volume and then do a SetFileInformationByHandleEx to do a move with POSIX semantics to deal with the potential race conditions ....)

11

Looks like maybe CopyFileEx is what you want?

12

I doubt it; from the same page:

CopyFile: If the destination file already exists and is a symbolic link, the symbolic link is overwritten by the source file.

Might fix the issue, however, I need to get an installer built to test it.

13

But what I was trying to highlight was CopyFileEx (different from CopyFile) which seems to have a flag COPY_FILE_COPY_SYMLINK which does: "If the destination file is an existing symbolic link, the symbolic link is overwritten, not the target file."

14

Right, the same page however seems to indicate that CopyFile has the same behavior supposedly (which I attempted to quote poorly).

15

Ah, I see. Interesting that the statement about CopyFile on that page seems to conflict with the docs on CopyFile's own page. Unless I am misreading (again), one says it overwrites the link, one says it overwrites the target.

Well anyway...

16

No, that is precisely what I came away with as well. This is why I am somewhat hesitant about CopyFileEx. Also the reason for CopyFile particularly is that is what underlies std::filesystem::copy_file on Windows. It seems safer to do the more convoluted thing of moving the file onto the volume and into place subsequently given that CopyFile has empirically shown a failure on replacement (assuming that is the cause of the error).

1 Like
17

I had the same problem (missing required module 'ucrt') after Visual Studio installed some additional packages (for unrelated reasons/another project), I had to install the Swift Toolchain again, it was OK then.

18

If you update/reinstall Visual Studio, you can simply repair the installation from the control panel.

19

You mean via configuration of the Toolchain installation via the Programs dialog of the Windows settings?

20

Sorry, I should've been more clear about that. Yes, that is what I was referring to. The newer versions of the Swift installer should allow you to repair the installation, which should also fix the issues if you install Swift before you have Visual Studio (or the Build Tools & WinSDK) installed.