Thanks for the feedback! That is indeed a case that we would’ve likely missed!
FoundationNetworking depends on curl, and we do not currently package that as the manifest was based on the dynamic library variant, which internalises curl.
As to the dynamic link failure: sScM6sharedScMvau is the MainActor in the standard library. I suspect that you are dynamically linking to the experimental SDK but running against the legacy SDK. Unfortunately, we cannot bundle both runtimes simultaneously, and currently you would need to use the MSM to inject the runtime into the executable destination.
A brief status update and a heads‑up on upcoming changes.
First, follow‑up on the earlier report: @Keithcat1, the issue you noted should be addressed in the latest snapshot. For projects using FoundationXML or FoundationNetworking with the static SDK, we now bundle libxml2, zlib, and curl to close external dependency gaps.
More broadly, I’m finishing the remaining changes required for the entire toolchain to build against the Win32 Side‑by‑Side (SxS)–enabled runtime. With the toolchain building cleanly against the SxS runtime, we have strong confidence that the experimental SDK is functionally complete and provides a solid basis for packaging and distribution.
With that in place, I plan to begin deprecating and removing the legacy SDK builds from the toolchain. We’ve had a sustained window for issue reports and blocker identification; consider this a final migration notice so users can validate workloads and raise any last concerns.
The new builds enable static linking against the Swift runtime and incorporate a more rigorous standard library build. Practically, this should reduce some overhead in common code paths. The trade‑off is ABI incompatibility across releases: binaries built against older runtime versions will not be interchangeable, as mixing libraries built with differing runtime ABIs is unsupported.
Our aim is that these changes unlock long‑requested workflows in the next release — particularly predictable deployment via static linkage and cleaner version isolation via SxS manifests. I’ll continue to share updates as the remaining work lands.
Note that the dispatch/swiftDispatch situation is something that will be fixed in follow up changes after we get the runtimes switched over.
After a long bit of silence, here is a small update.
We now have a new snapshot on swift.org (11/3). This should have the vast majority of the work complete. I think that we are at a point where things should be usable. I have at two separate cases where I am able to build fully statically linked binaries for distribution in GitHub Actions (GitHub - compnerd/vigil: A `caffeinate` inspired power management suspension program for Windows and GitHub - compnerd/nv: Ninja Visualizer if you would like to see examples). The Windows toolchain build also has adopted the snapshot for the static linking to get a working early swift-driver. I am currently working on adopting the experimental SDK (dynamic linkage) for the toolchain itself.
In parallel, @roman-bcny has managed to get SwiftFormat migrated over to the static linking on Windows as well.
I feel like the SDK is now in relatively good shape. There is still the small issue of fixing the libdispatch and libclosure builds converted to dynamic in all cases. Otherwise, this feels like we are nearly at the point of convergence.
Once the toolchain build has adopted the dynamic variant of the experimental SDK, the legacy SDK is going to be removed. Until that point, you will need to alter the SDKROOT when building, but hopefully this will be addressed soon, becoming the default SDK.