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

Open
troughton opened this issue Jan 27, 2018 · 1 comment
Open

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

troughton opened this issue Jan 27, 2018 · 1 comment
Assignees
Labels
bug A deviation from expected or documented behavior. Also: expected but undesirable behavior. cmake compiler The Swift compiler in itself runtime The Swift Runtime swift 4.0 Windows Platform: Windows

Comments

@troughton
Copy link
Contributor

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:

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
Copy link
Contributor Author

@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
Labels
bug A deviation from expected or documented behavior. Also: expected but undesirable behavior. cmake compiler The Swift compiler in itself runtime The Swift Runtime swift 4.0 Windows Platform: Windows
Projects
None yet
Development

No branches or pull requests

1 participant