Windows Nightlies


(Pedro José Pereira Vieito) #41

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.

(Pedro José Pereira Vieito) #42

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.

(Thomas Roughton) #43

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. is the (preexisting) Clang bug that seems to reference the same issue.

(Saleem Abdulrasool) #44

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?

(Jordan Rose) #45

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.

(Saleem Abdulrasool) #46

The macros are in the reserved namespace, so, if they collide I'm not too worried.

(JP Simard) #47

Thanks for all the efforts in getting Swift to build & run on Windows @compnerd!

Would it be possible to include SwiftPM in your nightlies?

(Saleem Abdulrasool) #48

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.

(Lars Sonchocky-Helldorf) #49

Hi @compnerd, what do you think are the chances we're getting a CI here: so that your great work on Windows doesn't break again?

(Karl) #50

SwiftPM does indeed require Foundation.

(Saleem Abdulrasool) #51

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.

(Lars Sonchocky-Helldorf) #52

Well, I have no idea about administering azure's services nor Jenkins (since I am not a DevOp) but googling for brought up quite some hits, some even by Microsoft, for my naive eye the most relevant seemed to be . Maybe somebody else has more knowledge in this area. I am sorry that I can't really help here.

(Saleem Abdulrasool) #53

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.

(Ru Sshy) #54

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 !

(Saleem Abdulrasool) #55

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.

(Robert Muckle-Jones) #56

Are there some instructions for how to use these windows nightlies? Do these nightlies require the instructions at to be followed first? I have been having trouble getting past stage 5.

(Pedro José Pereira Vieito) #57

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.

(Saleem Abdulrasool) #58

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.

(Robert Muckle-Jones) #59

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).

(Spencer Kohan) #60

This is fantastic, thanks for working on this!