Swift 5.8 toolchain on Windows fails to find core DLLs

[itaiferber]

I recently installed the Swift 5.8 toolchain on my machine via winget following the official installation instructions, and ran into two issues related to DLL loading that were surprisingly frustrating to debug. (I didn't post this in Swift Required DLLs on Windows 10 as that thread seems more related to Swift program distribution, and I'm just trying to run Swift locally here; though, if this is a good fit for that thread, happy to copy this over.)

The first roadblock: attempting to run swift.exe immediately presented dialogs indicating that swiftCore.dll, swiftWinSDK.dll, swiftCRT.dll, and swiftDispatch.dll could not be found, despite the fact that these DLLs had been successfully installed in C:\Program Files\swift\runtime-development\usr\bin, and were in the %PATH%. The solution was to copy the contents of this directory into C:\Library\Developer\Toolchains\unknown-Asserts-development.xctoolchain\usr\bin so that the DLLs were present alongside the executables in question.

The second roadblock: attempting to run swift.exe repl resulted in error: failed to retrieve frontend target info. Vaguely remembering having run into this in the past with LLDB, I tried running lldb.exe from the same directory, and got the same error dialog about python310.dll not being found (also despite being in my %PATH%). The solution was the same: copy python310.dll into the toolchain directory, and run again.

Having done both of those, I'm able to now run swift.exe repl, though:

1. Only from within the toolchain directory — otherwise I get error: failed to retrieve frontend target info again
2. Attempting to actually evaluate anything yields Assertion failed: false && "called into swift language runtime stub", file D:\a\1\s\llvm-project\lldb\source\Plugins\LanguageRuntime\Swift\SwiftLanguageRuntime.cpp, line 393, presumably because the runtime also isn't getting loaded correctly
3. Alternatively, attempting to compile a file without the repl leads either to the frontend target info error if running from a directory outside of the toolchain dir, or <unknown>:0: error: error opening input file '<path here>' (no such file or directory) if running from inside of it. (The file does exist and is accessible, but I suspect that some other failure just leads to this error line)

Knowing very little about Windows development, I'm wondering:

1. Am I doing something wrong here? Is there something about how the toolchain is packaged, or getting installed via winget that's leading to these issues, or is this somewhat expected?
2. Is it expected that these tools can't find the DLLs they're relying on, despite those DLLs being present in the %PATH%? I know DLL loading is complex, but from my very limited knowledge, I would expect these things to Just Work™ (famous last words!). Is there something I need to manually do to get dynamic loading to work?
3. Is there a good path forward here in terms of reporting these issues? I'm just messing around with Swift on my PC here, so this is super low-stakes for me, but I do want to help if I can. (The LLDB python310.dll issue, for example, appears to come up every now and again on llvm/llvm-project, but it seems that most of those are resolved by the original authors once they learn to copy python3<x>.dll into the LLDB dir — but this doesn't feel sustainable.) Are there more central issues tracking these problems, and if not, do we want there to be?

/CC @compnerd as the person most likely to be able to comment on some of these issues, though I don't mean to just dump this wall of text directly on you! Thanks for any help, and please let me know how I might be able to contribute back!

[compnerd (Saleem Abdulrasool)]

@itaiferber

The first roadblock: attempting to run swift.exe immediately presented dialogs indicating that swiftCore.dll, swiftWinSDK.dll, swiftCRT.dll, and swiftDispatch.dll could not be found, despite the fact that these DLLs had been successfully installed in C:\Program Files\swift\runtime-development\usr\bin, and were in the %PATH%. The solution was to copy the contents of this directory into C:\Library\Developer\Toolchains\unknown-Asserts-development.xctoolchain\usr\bin so that the DLLs were present alongside the executables in question.

This is definitely the wrong thing to do. The files should not need to be copied. Ensure that you reboot after installation - overkill but ensures the right behaviour. You need to terminate ALL Windows Terminal instances, and then re-launch it. The path adjustment will not take effect otherwise. Once you do that you can verify that your Path environment variable contains the desired path by checking it via the path command in CMD or echo $env:Path in PowerShell.

@itaiferber

The second roadblock: attempting to run swift.exe repl resulted in error: failed to retrieve frontend target info. Vaguely remembering having run into this in the past with LLDB, I tried running lldb.exe from the same directory, and got the same error dialog about python310.dll not being found (also despite being in my %PATH%). The solution was the same: copy python310.dll into the toolchain directory, and run again.

Again, copying the DLLs around is not the preferred solution. Installation of python properly should place that into your path. If not, you will need to adjust your user path to add Python to the path.

@itaiferber

Having done both of those, I'm able to now run swift.exe repl, though:

Sadly this works only partially. This is one of the things that needs to be resolved but there are roadblocks within LLDB that prevent this from being resolved imminently. The library search path handling is not sufficiently flexible to allow us to ensure that Path is honoured as a library search path.

@itaiferber

• Attempting to actually evaluate anything yields Assertion failed: false && "called into swift language runtime stub", file D:\a\1\s\llvm-project\lldb\source\Plugins\LanguageRuntime\Swift\SwiftLanguageRuntime.cpp, line 393, presumably because the runtime also isn't getting loaded correctly

Indeed this is the issue; again, this is something that is the result of the LLDB implementation being rigid. We would like to honour the SDKROOT environment variable as it does on Darwin, however, that path is not shared. This is worked around by doing lldb --repl="-sdk %SDKROOT%" from CMD, but then you hit the issue of Path not being honoured for library lookups. That is worked around by manually mapping in the transitive closure of the shared libraries (aka, Not Fun ). I recommend that you subscribe to the fairly old issue tracking this work.

@itaiferber

• Am I doing something wrong here? Is there something about how the toolchain is packaged, or getting installed via winget that's leading to these issues, or is this somewhat expected?

Yes, namely trying to use the REPL . The recommendation currently is unless you really really know what you are doing, prefer to use the compiler over the REPL.

@itaiferber

• Is it expected that these tools can't find the DLLs they're relying on, despite those DLLs being present in the %PATH%? I know DLL loading is complex, but from my very limited knowledge, I would expect these things to Just Work™ (famous last words!). Is there something I need to manually do to get dynamic loading to work?

No, that is not expected. I do occasionally get bitten by this during smoke testing the updates. Restarting the terminal is annoying but then again, Linux doesn't handle this much better.

@itaiferber

1. Is there a good path forward here in terms of reporting these issues? I'm just messing around with Swift on my PC here, so this is super low-stakes for me, but I do want to help if I can. (The LLDB python310.dll issue, for example, appears to come up every now and again on llvm/llvm-project, but it seems that most of those are resolved by the original authors once they learn to copy python3<x>.dll into the LLDB dir — but this doesn't feel sustainable.) Are there more central issues tracking these problems, and if not, do we want there to be?

Yes, please continue reporting these issues, even if they are duplicates. The ideal place is on the issues tab on GitHub, but starting threads on the forums for discussions is reasonable as well. The Python dependency issue is something that I'm really frustrated about. I don't know what the best solution here is. Is it better to subsume the responsibility for Python and use the embeddable distribution and distribute it ourselves, increasing the size of the toolchain, vulnerability surface, etc or rely on the user having python installed. I'm not a fan of either option, but I don't see a better solution yet.

[itaiferber]

Thanks for taking the time to look at this, @compnerd!

@compnerd

Ensure that you reboot after installation - overkill but ensures the right behaviour. You need to terminate ALL Windows Terminal instances, and then re-launch it. The path adjustment will not take effect otherwise. Once you do that you can verify that your Path environment variable contains the desired path by checking it via the path command in CMD or echo $env:Path in PowerShell.

Ah, I should have specified: I'm aware of this limitation, and restarted the terminal and confirmed that my Path had correctly updated. In writing this up, I also restarted my machine just in case, and in re-confirming, honed in more directly on the issue I'm seeing: this appears to only be happening in WSL, and not from a regular command prompt. (I happen to use WSL as my main driver for development, and I'm not usually thinking of the difference in environment.)

Command prompt:

$ where swiftCore.dll
C:\Program Files\swift\runtime-development\usr\bin\swiftCore.dll

$ where swift.exe
C:\Library\Developer\Toolchains\unknown-Asserts-development.xctoolchain\usr\bin\swift.exe

$ swift.exe repl
Welcome to compnerd.org Swift version 5.8 (swift-5.8-RELEASE).
Type :help for assistance.
1> ^C

%Path%

C:\Program Files\WindowsApps\Microsoft.WindowsTerminal_1.16.10261.0_x64__8wekyb3d8bbwe;C:\Program Files\Eclipse Adoptium\jdk-17.0.6.10-hotspot\bin;C:\Program Files\Microsoft MPI\Bin\;C:\ProgramData\Oracle\Java\javapath;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\WINDOWS\System32\WindowsPowerShell\v1.0\;C:\Program Files\OpenVPN\bin;C:\WINDOWS\System32\OpenSSH\;C:\Program Files\NVIDIA Corporation\NVIDIA NvDLISR;C:\Users\itai\.cargo\bin;C:\Users\itai\AppData\Local\Microsoft\WindowsApps;C:\Program Files\Sublime Text 3;C:\Program Files (x86)\Microsoft VS Code\bin;C:\Users\itai\AppData\Local\Programs\Microsoft VS Code Insiders\bin;C:\Users\itai\AppData\Roaming\npm;C:\Program Files\Java\jre1.8.0_211\bin;C:\Users\itai\AppData\Roaming\local\bin;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\WINDOWS\System32\WindowsPowerShell\v1.0\;C:\WINDOWS\System32\OpenSSH\;C:\Program Files\dotnet\;C:\Program Files (x86)\dotnet\;C:\Program Files (x86)\NVIDIA Corporation\PhysX\Common;C:\Program Files\usbipd-win\;C:\Program Files (x86)\AOMEI;C:\Program Files (x86)\Windows Kits\10\Windows Performance Toolkit\;C:\Program Files\Git\cmd;C:\Program Files\nodejs\;C:\Program Files\Mullvad VPN\resources;C:\Program Files\AMD\AMDuProf\bin;C:\Program Files\swift\runtime-development\usr\bin;C:\Library\Developer\Toolchains\unknown-Asserts-development.xctoolchain\usr\bin;C:\Program Files\LLVM\bin;C:\Users\itai\AppData\Local\Programs\Python\Python310\Scripts\;C:\Users\itai\AppData\Local\Programs\Python\Python310\;C:\Users\itai\.cargo\bin;C:\Users\itai\AppData\Local\Microsoft\WindowsApps;C:\Program Files\Sublime Text 3;C:\Program Files (x86)\Microsoft VS Code\bin;C:\Users\itai\AppData\Local\Microsoft\WindowsApps;C:\Program Files\MKVToolNix;C:\Users\itai\AppData\Local\Programs\espanso;C:\Users\itai\AppData\Roaming\cabal\bin;C:\tools\ghc-9.2.2\bin;C:\ghcup\bin;C:\Users\itai\AppData\Local\Programs\Microsoft VS Code\bin;C:\Users\itai\AppData\Roaming\npm;

In WSL:

$ which swiftCore.dll
/mnt/c/Program Files/swift/runtime-development/usr/bin/swiftCore.dll

$ which swift.exe
/mnt/c/Library/Developer/Toolchains/unknown-Asserts-development.xctoolchain/usr/bin/swift.exe

$ swift.exe repl

$PATH

/home/itai/.bin /home/itai/.local/bin /home/itai/.ghcup/bin /usr/local/sbin /usr/local/bin /usr/sbin /usr/bin /sbin /bin /usr/games /usr/local/games /usr/lib/wsl/lib /mnt/c/Program Files/WindowsApps/Microsoft.WindowsTerminal_1.16.10261.0_x64__8wekyb3d8bbwe /mnt/c/Program Files/Eclipse Adoptium/jdk-17.0.6.10-hotspot/bin /mnt/c/Program Files/Microsoft MPI/Bin/ /mnt/c/ProgramData/Oracle/Java/javapath /mnt/c/Windows/system32 /mnt/c/Windows /mnt/c/Windows/System32/Wbem /mnt/c/Windows/System32/WindowsPowerShell/v1.0/ /mnt/c/WINDOWS/system32 /mnt/c/WINDOWS /mnt/c/WINDOWS/System32/Wbem /mnt/c/WINDOWS/System32/WindowsPowerShell/v1.0/ /mnt/c/Program Files/OpenVPN/bin /mnt/c/WINDOWS/System32/OpenSSH/ /mnt/c/Program Files/NVIDIA Corporation/NVIDIA NvDLISR /mnt/c/Users/itai/.cargo/bin /mnt/c/Users/itai/AppData/Local/Microsoft/WindowsApps /mnt/c/Program Files/Sublime Text 3 /mnt/c/Program Files (x86)/Microsoft VS Code/bin /mnt/c/Users/itai/AppData/Local/Programs/Microsoft VS Code Insiders/bin /mnt/c/Users/itai/AppData/Roaming/npm /mnt/c/Program Files/Java/jre1.8.0_211/bin /mnt/c/Users/itai/AppData/Roaming/local/bin /mnt/c/WINDOWS/system32 /mnt/c/WINDOWS /mnt/c/WINDOWS/System32/Wbem /mnt/c/WINDOWS/System32/WindowsPowerShell/v1.0/ /mnt/c/WINDOWS/System32/OpenSSH/ /mnt/c/Program Files/dotnet/ /mnt/c/Program Files (x86)/dotnet/ /mnt/c/Program Files (x86)/NVIDIA Corporation/PhysX/Common /mnt/c/Program Files/usbipd-win/ /mnt/c/Program Files (x86)/AOMEI /mnt/c/Program Files (x86)/Windows Kits/10/Windows Performance Toolkit/ /mnt/c/Program Files/Git/cmd /mnt/c/Program Files/nodejs/ /mnt/c/Program Files/Mullvad VPN/resources /mnt/c/Program Files/AMD/AMDuProf/bin /mnt/c/Program Files/swift/runtime-development/usr/bin /mnt/c/Library/Developer/Toolchains/unknown-Asserts-development.xctoolchain/usr/bin /mnt/c/Program Files/LLVM/bin /mnt/c/Users/itai/AppData/Local/Programs/Python/Python310/Scripts/ /mnt/c/Users/itai/AppData/Local/Programs/Python/Python310/ /mnt/c/Users/itai/.cargo/bin /mnt/c/Users/itai/AppData/Local/Microsoft/WindowsApps /mnt/c/Program Files/Sublime Text 3 /mnt/c/Program Files (x86)/Microsoft VS Code/bin /mnt/c/Users/itai/AppData/Local/Microsoft/WindowsApps /mnt/c/Program Files/MKVToolNix /mnt/c/Users/itai/AppData/Local/Programs/espanso /mnt/c/Users/itai/AppData/Roaming/cabal/bin /mnt/c/tools/ghc-9.2.2/bin /mnt/c/ghcup/bin /mnt/c/Users/itai/AppData/Local/Programs/Microsoft VS Code/bin /mnt/c/Users/itai/AppData/Roaming/npm /usr/bin/site_perl /usr/bin/vendor_perl /usr/bin/core_perl

I'm seeing exactly the same behavior for lldb.exe with python310.dll, so this is both not unique to swift.exe, and is also definitely related to WSL specifically.

So... I'd ask "is there a reason to expect this to not work under WSL?", but I suspect that WSL is a different-enough beast that it's not unexpected that things don't work the same, yeah? At least, it seems that DLL loading working differently when executing things through WSL is more of a Microsoft issue — unless you're aware of some possible misconfiguration on my end?

---

@compnerd

Yes, namely trying to use the REPL . The recommendation currently is unless you really really know what you are doing, prefer to use the compiler over the REPL.

This is good to know, and I'll avoid going through the REPL, then!

FWIW, though this may be a different issue entirely, it appears that this may also extend to running a file directly with the swift front-end; compiling with swiftc does at least work:

$ swift test.swift
<unknown>:0: error: could not load the swift standard library

$ swiftc test.swift
   Creating library test.lib and object test.exp

$ test.exe
Hello, world!

---

@compnerd

Yes, please continue reporting these issues, even if they are duplicates.

Will do, and thanks for the help! (If you think it's worth filing an issue for WSL specifically, happy to do that too!)

[compnerd (Saleem Abdulrasool)]

@itaiferber

So... I'd ask "is there a reason to expect this to not work under WSL?", but I suspect that WSL is a different-enough beast that it's not unexpected that things don't work the same, yeah? At least, it seems that DLL loading working differently when executing things through WSL is more of a Microsoft issue — unless you're aware of some possible misconfiguration on my end?

Yeah, WSL is sufficiently different that I suspect that things are not going to work immediately. I don't even know how to debug the issue here because you are not going to be using the MinGW loader as the binaries are not ELF. Normally we can at least use +sls to figure out what is going on with the loader or LD_DEBUG=all but here I have no idea how to trace what is going on.

@itaiferber

FWIW, though this may be a different issue entirely, it appears that this may also extend to running a file directly with the swift front-end; compiling with swiftc does at least work:

swift runs the interpreter rather than the compiler, which is the same path as the REPL. Again, something I want to get stable and solid, but debugging and SPM support is more important IMO. Help is absolutely welcome!

[itaiferber]

Got it — that all makes sense. Thanks again for taking time on this!

I'd love to be able to eventually help contribute back, with a bit more Windows knowledge.