Hey everyone! I have been trying to follow all the steps given to download swift, but when i try and run anything i get this error message. But, in VScode's terminal I am able to run swift repl perfectly. Any idea what could have gone wrong? I am using windows 11 and have checked that SDKROOT is in the systems variables. Any help would be very much appreciated!
1 Like
You might want to put âwindowsâ in the post title to get the attention of the experts on that platform.
Thanks Kyle! Added it.
Speaking generally, that means the compiler could not find the standard library, often because the triple you're using to compile is different from the triple the standard library was built with. Compile with the -v flag and check what -sdk or -resource-dir the compiler is looking for the stdlib in, and make sure the stdlib swiftmodules are in there and that the triples they use match your -target. Most likely you haven't setup the toolchain properly for Windows.
Really appreciate the reply! Honestly, as I'm no expert in the field, i am not able to properly follow your advice to check if the stdlib swiftmodules are there. i tried running -v .<file_name.swift> in my VS Code terminal but i am getting an error saying that the term "-v" is not recognized as the name of a cmdlet, function, script file, or operable program. What is the correct way to compile with this flag to be able to proceed with the next steps? Thank you for your time!
I've never used VS Code, so I can't help you with that. @ColemanCDA, you appear to use it, any tips?
I only use it on macOS and Linux, @compnerd is the Windows platform champion. I just got VS Code extension configured for WASM, so you might wanna try on macOS or Linux and just specify the SDK and triple.
This is due to limitations in LLDB's codebase. I've posted multiple times in great detail what the issue is but no one else seems to be stepping up to do the work. I recommend that you compile and execute the code instead of trying to use the REPL.
You should be able to forcefully load the standard library and dependencies by explicitly mapping in the dependent DLLs in reverse post-order traversal and set the library search path. That is sufficient to enable the REPL. There are examples of that in GH issues as well as the forums.
Hello Saleem! Thank you for the detailed reply. I had already seen your replies on other posts talking about similar issues, but I thought as we are talking about an older module of Swift I wouldn't be encountering such issues myself (running Swift v5.7.1), as it is stated here (Swift.org - Getting Started) that support files are only required for versions older than 4.5.2.
Circling back to the issue, I had a hard time understanding some of the terms you used as I'm a beginner in this whole space. but, from what I could grasp and following your reply on a previous post, should i try running this in my command prompt?
set SDKROOT=%SystemDrive%\Library\Developer\Platforms\Windows.platform\Developer\SDKs\Windows.sdk
copy "%SDKROOT%\usr\share\ucrt.modulemap" "%UniversalCRTSdkDir%\Include\%UCRTVersion%\ucrt\module.modulemap"
copy "%SDKROOT%\usr\share\visualc.modulemap" "%VCToolsInstallDir%\include\module.modulemap"
copy "%SDKROOT%\usr\share\visualc.apinotes" "%VCToolsInstallDir%\include\visualc.apinotes"
copy "%SDKROOT%\usr\share\winsdk.modulemap" "%UniversalCRTSdkDir%\Include\%UCRTVersion%\um\module.modulemap"
Again, thank you for your time and I hope that through this post, some people that are currently around my level of expertise could easily fix any related issues that they might encounter!
No, the deployment of the module map files is now handled by the installer and is automated. The problem here is that the search path handling in lldb doesnât properly account for differences in platforms. There is no concept of rpath and as such the necessary DLLd need to be explicitly looked up and mapped. You need to work outside of the REPL to load and map then before you can use the REPL.
Ok Saleem, I tried looking it up but couldn't find any sources explaining how to follow these steps. Can you link me to where you went over them or any sources you have explaining how to do it? That would be very much appreciated!
[SR-13591] REPL is not working on swift-5.3-RELEASE (Windows) ¡ Issue #56026 ¡ apple/swift ¡ GitHub is a more thorough example, though some of the same bits are replicated at LLDB crashes when loading local variables - #2 by compnerd.
I imagine that there are a few more cases around on the forums and GitHub issues.
Although the REPL does work, it continuously regresses, and there is currently insufficient help to keep it in a great shape. It would be good to get more community support to keep the REPL in a working state at all times on Windows.
Thank you very much! Does this still apply to my case even if my swift REPL
is working?
Yes, it still does apply as it ends up being the issue that the search paths are incorrect so you are not even getting to that point. Note the swift -- -sdk %SDKROOT% invocation in the example.
Something along the lines of:
>type \lldb.init
settings set target.sdk-path "S:\Library\Developer\Platforms\Windows.platform\Developer\SDKs\Windows.sdk"
process load S:\Library\swift-development\usr\bin\x64\swiftCore.dll
>lldb -x -S \lldb.init --repl
might do the trick?
Tried to run first command, says system cannot find the file specified, and when i tried running the lldb, it says the "the code execution cannot proceed because python310.dll was not found". I tried reinstalling python 3.10 but nothing changed. And now, I tried running the swift repl again and this error shows up. Assertion failed: false && "called into swift language runtime stub", file D:\a\1\s\llvm-project\lldb\source\Plugins\LanguageRuntime\Swift\SwiftLanguageRuntime.cpp, line 392 PLEASE submit a bug report to https://bugs.llvm.org/ and include the crash backtrace. #0 0x00007ff7f90c4bd5 (C:\Library\Developer\Toolchains\unknown-Asserts-development.xctoolchain\usr\bin\lldb.exe+0x24bd5) #1 0x00007ff80bf2e5f5 (C:\WINDOWS\System32\ucrtbase.dll+0x7e5f5) #2 0x00007ff80bf2f601 (C:\WINDOWS\System32\ucrtbase.dll+0x7f601) #3 0x00007ff80bf3106a (C:\WINDOWS\System32\ucrtbase.dll+0x8106a) #4 0x00007ff80bf30f5d (C:\WINDOWS\System32\ucrtbase.dll+0x80f5d) #5 0x00007ff80bf311f1 (C:\WINDOWS\System32\ucrtbase.dll+0x811f1) #6 0x00007fff32c61559 PyInit__lldb (C:\Library\Developer\Toolchains\unknown-Asserts-development.xctoolchain\usr\bin\liblldb.dll+0x6d1559) #7 0x00007fff37e84ce4 PyInit__lldb (C:\Library\Developer\Toolchains\unknown-Asserts-development.xctoolchain\usr\bin\liblldb.dll+0x58f4ce4) #8 0x00007fff37e8a93b PyInit__lldb (C:\Library\Developer\Toolchains\unknown-Asserts-development.xctoolchain\usr\bin\liblldb.dll+0x58fa93b) #9 0x00007fff37e87eea PyInit__lldb (C:\Library\Developer\Toolchains\unknown-Asserts-development.xctoolchain\usr\bin\liblldb.dll+0x58f7eea) #10 0x00007fff37e8233b PyInit__lldb (C:\Library\Developer\Toolchains\unknown-Asserts-development.xctoolchain\usr\bin\liblldb.dll+0x58f233b) #11 0x00007fff32976bac PyInit__lldb (C:\Library\Developer\Toolchains\unknown-Asserts-development.xctoolchain\usr\bin\liblldb.dll+0x3e6bac) #12 0x00007fff32985802 PyInit__lldb (C:\Library\Developer\Toolchains\unknown-Asserts-development.xctoolchain\usr\bin\liblldb.dll+0x3f5802) #13 0x00007fff32953206 PyInit__lldb (C:\Library\Developer\Toolchains\unknown-Asserts-development.xctoolchain\usr\bin\liblldb.dll+0x3c3206) #14 0x00007fff328fe62a PyInit__lldb (C:\Library\Developer\Toolchains\unknown-Asserts-development.xctoolchain\usr\bin\liblldb.dll+0x36e62a) #15 0x00007fff328fc4ee PyInit__lldb (C:\Library\Developer\Toolchains\unknown-Asserts-development.xctoolchain\usr\bin\liblldb.dll+0x36c4ee) #16 0x00007ff80bed9363 (C:\WINDOWS\System32\ucrtbase.dll+0x29363) #17 0x00007ff80dc8244d (C:\WINDOWS\System32\KERNEL32.DLL+0x1244d) #18 0x00007ff80e5cdfb8 (C:\WINDOWS\SYSTEM32\ntdll.dll+0x5dfb8).
Appreciate you sticking with me.
1 Like
Yes, the first command fails because that was something local that I was sharing the contents of. It indicated what the contents of the file are. You will need to create the file and adjust the contents to have it work.
The solution should be very easy: use swiftc.exe instead of swift.exe
Simplest method:
-
Installation using swift-5.7.3-RELEASE-windows10.exe on Microsoft Windows 10 Professional
-
Tested it with a file
helloworld.swift
containing
print( "Hello world" ) -
Then running (adapt the path to swiftc.exe to your system)
swiftc.exe helloworld.swift
created a file
helloworld.exe
which when run did print
Hello world -
Using swift.exe instead gave the mentioned error at first.
-
Note: no extra variables have been set, like SDKROOT for example.
2 Likes
Yes, swift will interpret the code, which is not yet as reliable on Windows. The compilation path should be stable though.
1 Like