Also, to be clear, the OSS version of Foundation is written in Swift and it is intended to be source-compatible with the Darwin Objective-C based version while not requiring the Objective-C runtime.
Have been trying Dispatch and it seems to work great, thanks!
I don't know if it is the same error, but when I try to import WinSDK after installing the modulemap swiftc always throws a lot of import errors referencing that some type is unknown (eg. error: "No Target Architecture" or error: unknown type name 'PSLIST_HEADER'). On the other hand, the MSVCRT module (and the underlying ucrt and visualc) works great.
That’s the same error, although I’m a little surprised you’re not seeing it with MSVCRT; I also ran into it with importing uint64_t from stdint.h. If you manually edit the WinSDK header files to change the #pragma once guards to #ifndef/#define pairs it should work.
39206 – [Modules TS] #pragma once leaks out of module files in a way that macros do not is the (preexisting) Clang bug that seems to reference the same issue.
Great to hear that libdispatch is working great for you!
Oh, right, thats under-documented, I'm sorry. I don't know where to put such a document. You need to specify the architecture that you are targeting when you compile unfortunately (cl requires that too). Adding -Xcc -D_AMD64_ or -Xcc -D_X86_ should resolve the issue with import WinSDK.
@jrose, what do you think of adding this in the frontend based on the triple?
1 Like
That definitely seems reasonable to me. Clang predefines a whole bunch of macros like that on its own, so adding these few more (on Windows only) doesn't seem harmful. I suppose there's a chance someone wants to compile for Windows without using WinSDK, and might be using these names for something else, but that seems very unlikely.
The macros are in the reserved namespace, so, if they collide I'm not too worried.
Thanks for all the efforts in getting Swift to build & run on Windows @compnerd!
Would it be possible to include SwiftPM in your nightlies?
You're welcome :-). Unfortunately, I don't think that it is possible to include s-p-m just yet. I am still working on porting swift-corelibs-foundation to Windows. However, if I am mistaken and there is no dependency on Foundation for s-p-m, then assuming that the building s-p-m is as easy as libdispatch or Foundation (e.g. running CMake) then I can certainly include it.
1 Like
Hi @compnerd, what do you think are the chances we're getting a CI here: GitHub - apple/swift-community-hosted-continuous-integration: Swift Community-Hosted Continuous Integration so that your great work on Windows doesn't break again?
SwiftPM does indeed require Foundation.
Unfortunately, I am using azure's services, not Jenkins for this, so I don't know how to integrate this into the community CI. If you have a way to integrate this into the community CI system, I would be thrilled to see that happen.
1 Like
Well, I have no idea about administering azure's services nor Jenkins (since I am not a DevOp) but googling for azure services jenkins integration - Google Search brought up quite some hits, some even by Microsoft, for my naive eye the most relevant seemed to be Overview of Jenkins and Azure | Microsoft Learn . Maybe somebody else has more knowledge in this area. I am sorry that I can't really help here.
1 Like
Yeah, devops is not what I normally work on either, so this is something foreign to me. I'm still busy making the compiler/runtime/standard library/support libraries work, and doing the CI stuff as best as I can. There is a bunch of work still left in the compiler/runtime that I'm still focused on, so if someone familiar with devops/azure takes a look at this, it would be helpful.
1 Like
This is just awesome, thanks a lot for your hardwork; i wish i was skilled enough to be able to contribute
I can still try to help with porting the CI system to the community one, low level native development isn't my thing, but i will try !
1 Like
Since a number of folks are interested in the nightlies, I've added a preliminary attempt to add lldb to builds as well. The latest toolchain builds should have a bundled lldb there as well!
I'm still toying around with trying to build an android standard library, if I can get the build system to not depend on the toolchain artifacts I should be able to get the standard library and some of the core libraries built for android as nightlies that can be used as a SDK to cross-compile from Windows.
2 Likes
Are there some instructions for how to use these windows nightlies? Do these nightlies require the instructions at swift/WindowsBuild.md at main · apple/swift · GitHub to be followed first? I have been having trouble getting past stage 5.
The nightlies are pre-build toolchains so you only have to decompress them, download ICU libraries and add its DLLs directories to the PATH system environment variable and swiftc should just work.
1 Like
Indeed, that is correct. However, just to help make it easier for others, I've added some text describing that process. I believe that it also should cover the issue that you ran into @pvieito as it wasn't immediately apparent to you that the modulemaps were needed.
3 Likes
Thank you @pvieito and @compnerd that is very helpful. I am sorry to continue asking beginner questions but I got a linker error when I tried to compile a simple HelloWorld swift program.
C:\Users\rmj\Developer\Fizzbuzz>swiftc main.swift
Creating library main.lib and object main.exp
LINK : error LNK2001: unresolved external symbol mainCRTStartup
C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.16.27023\lib\x86\libcmt.lib : warning LNK4272: library machine type 'x86' conflicts with target machine type 'x64'
C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.16.27023\lib\x86\msvcrt.lib : warning LNK4272: library machine type 'x86' conflicts with target machine type 'x64'
C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.16.27023\lib\x86\msvcprt.lib : warning LNK4272: library machine type 'x86' conflicts with target machine type 'x64'
main : fatal error LNK1120: 1 unresolved externals
clang++.exe: error: linker command failed with exit code 1120 (use -v to see invocation)
<unknown>:0: error: link command failed with exit code 1120 (use -v to see invocation)
I clearly need to set the target machine type 'x64' to match the library machine type 'x86' but I haven't been able to work out how to do this. (FYI I am using Windows10 via Parallels on a 2017 iMac).
This is fantastic, thanks for working on this!
2 Likes