Announcing Swift 5.9.1 for Linux and Windows

We are happy to announce the release of Swift 5.9.1 for Linux and Windows.
New downloads are available on - Download Swift

Release Notes

  • Macros support on Windows platform
  • Windows toolchain built on infrastructure and signed by Apple
  • Enable frame pointers when building Swift libraries on Linux

Security Fix

  • Windows toolchain contains security fix for curl

There are no Windows builds listed on yet, right? I assume it is built and tested on Windows 11, and not on Windows 10? There might be edge cases where those two OS versions behave differently.

Interesting, I don't know how the build would impact that, only the SDK version and the host should be the important aspect (e.g. even if you build on Windows 7, it shouldn't matter as long as the minimum OS requirement is 10). Do you have any concrete examples that should be explicitly tested?

We have a project that compiles fine with Swift 5.9(.0) on macOS, on Ubuntu 22, and on Windows 11, but on Windows 10 we get the error "'main' attribute cannot be used in a module that contains top-level code". We get this error on two different Windows 10 installations (only those two tried).

Unfortunately the project is closed source so I cannot give it to you, I would have to reduce the project accordingly (I should try). (Just a few details: It is a project using the swift argument parser 1.0.1 and uses another package that is located siede-by-side, referenced via .package(path: ...), this referenced package uses another package with C code that is only compiled on Windows.)

From my experience I expect Microsoft to be very cautious concerning changes for one major OS version, but to be a little bit more "generous" concerning changes between major OS versions. So given that the project does not compile on two Windows 10 installations but compiles on a Windows 11 let us suspect that Windows 10 vs. Windows 11 might be causing the difference. Of course, this is so far only speculation, but this why I wanted to see at if a specified version of Windows is used for the CI.

This problem was also mentioned in another topic and maybe this Windows 10 vs. 11 thing might be indeed an issue.

Are you using the same Visual Studio (MSVC) version and Windows SDK version? It’s weird that Windows breaks the compatibility, because internally Windows 10 to 11 has no major version bump.

Regarding one Windows 10 system and the Windows 11 system, both Visual Studio installations were up to date, using MSVC v143, and both used Windows 10 SDK 10.0.19041.0. I now changed the SDK to Win 11 SDK 10.0.22621.0 on the Windows 10 machine (because on the Windows 11 SDK is used), but no luck.

Can you provide some links that explain the frame pointer part? Does it lead to shorter compile time?

Swift 5.9.1 seems to be missing on linux, whereas Swift 5.9.0 used to have it.

./tool: error while loading shared libraries: cannot open shared object file: No such file or directory

Is this the expected behavior?

Swift was installed on Linux using swiftly install latest . To fix this, I changed it to swiftly install 5.9.0 .


It wouldn't shorten the compile times, if anything, it could increase it. It would however improve debugging. FPO is optional on Linux, but does increase register pressure in favour of a much better debugging experience even on release builds.

1 Like

Can you give more info on which prebuilt toolchain you're installing? I just checked the 5.9.1 toolchain I downloaded four days ago and it is there for me:

> ag --search-binary swift-5.9.1-RELEASE-ubuntu20.04
Binary file swift-5.9.1-RELEASE-ubuntu20.04/usr/lib/swift/linux/ matches.

One regression found was that the toolchain installer doesn’t set the version correctly, making it a default 0.0.0. Is this something recognized and going to be fixes in the following releases?

After more investigation it is because the cli tools was build with swift 5.9.0 and run with swift 5.9.1.

In the other topic there is a public project mentioned that has the same problem and so anyone should be able to test the issue, and I suppose this other topic is the right place to continue any discussion of the issue.

@stevapple thanks for this; please do file an issue for this. We should fix the release process to ensure that we correctly pass along the version information to the build.