[SR-6858] Swift Static-Stdlib on Windows doesn't build correctly

[troughton]

Previous ID	SR-6858
Radar	None
Original Reporter	@troughton
Type	Bug

Environment

Windows 10

Additional Detail from JIRA

Votes	0
Component/s	Compiler
Labels	Bug, CMake, Runtime, Swift4, Windows
Assignee	@troughton
Priority	Medium

md5: aba5ec98aaa977fb16b11c23fbad793b

relates to:

• SR-10625 tests for -static-*

Issue Description:

For the static stdlib to build correctly on Windows, DLL storage needs to be disabled (within IRGen) and dllimport needs to be disabled.

This requires building the source files within the runtime twice, and also requires that IRGen has knowledge of whether modules will be linked statically or dynamically, since that affects what visibility symbols should have.

In addition, the static libraries are currently output as lib(library).a rather than (library).lib, and swiftCore.lib should be statically linked with ICU.

[troughton]

@jro @belkadan I’m guessing your comment on SR-6857 might’ve been meant for here?
In any case, I should clarify what’s going on here.
When building for Windows, the Swift project does currently apply dllimport/dllexport linkage for symbols, which enables the generated object files to be used for dynamic linking. However, when you try to statically link with those object files (and static linking is the only think that works right now due to other issues), the DLL storage semantics are incorrect and cause it to be unable to be linked.
The solution I have in mind here is to build the runtime and swiftCore twice: once with DLL storage (to build the dynamic libraries) and once without (to build the static libraries).
The difficulty involving IRGen comes from the fact that if we’re building a module that may be statically linked to some libraries and dynamically to others, we need to know what linkage to give the symbols on a per-module basis
I should note that the Windows build (i.e. building working Swift programs) is actually fully functional with a few minor patches (PRs incoming) and a workaround to SR-6857 in place (say, to allow LLD to ignore multiple definitions of symbols).