Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

troughton opened this issue Jan 27, 2018 · 1 comment

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

troughton opened this issue Jan 27, 2018 · 1 comment


Copy link

@troughton troughton commented Jan 27, 2018

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

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:

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.

Copy link
Contributor Author

@troughton troughton commented Jan 29, 2018

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

@swift-ci swift-ci transferred this issue from apple/swift-issues Apr 25, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet

No branches or pull requests

1 participant