IRGen: support static linking on Windows #37211
Conversation
If the `-static` option is specified, store that in the generated swiftmodule file. When de-serializing, recover this information in the representative SILModule. This will be used for code generation on Windows. It is the missing piece to allow static linking to function properly. It additionally opens the path to additional optimization on ELF-ish targets - GOT, PLT references can be avoided when the linked module is known to be static. Co-authored by: Saleem Abdulrasool <[email protected]>
This adjusts the IRGen layer to accommodate the Windows linking model. We assume dynamic linking by default. The static linking is enabled by passing `-static` to the driver, which forwards it to the frontend when building the module statically. This has already been required when generating libraries, however, the non-Windows targets are more forgiving and let it work. On those platforms, using this hint would allow for more efficient code generation, reducing load times and some runtime penalties from the PLT and GOT references formed to symbols which are module local. This corrects static linking on Windows, which is one of the last few items that are missing on Windows. It also takes advantage of the hint for the one peculiar difference between Windows and non-Windows: protocol conformances that span module boundaries are not available as a constant. However, when statically linking, we can enable those conformances to be statically resolved. This should enable the last known pattern to work when using static linking. This support requires further work in the Swift Package Manager to actually enable building libraries properly. However, when building with CMake, this should be sufficient to enable static linking.
|
@swift-ci please test |
|
Build failed |
|
Hmm, this might be mishandling C/C++ linkage. |
|
Having this as a bit in the AST seems like a huge layering violation. A swiftmodule doesn't have to have anything to do with the final binary image on disk, and one could conceivably share a swiftmodule between a static archive and a dylib if they so choose. Is there a way for us to divine this from the link arguments? |
|
@CodaFi nope, link time is too late. This needs to be available before compiling. We need to know at compile time if the module is statically or dynamically linked. I had brought up this idea at https://forums.swift.org/t/enabling-static-linking-on-windows/40509/10. I'm open to another solution if you have one. |
|
@swift-ci please test Linux platform |
|
Discussed this with @compnerd further and there isn't really a good alternative either of us could identify. Approving so we can make progress here. The ABI isn't set in stone on Linux or Windows so we have the opportunity to amend this in the future if need be. |
Replace this paragraph with a description of your changes and rationale. Provide links to external references/discussions if appropriate.
Resolves SR-NNNN.