Hello Swift Community,
The review of SE-0482: Binary Static Library Dependencies ran from May 2nd through May 15th, 2025.
Feedback was light, overall positive, and fully agreeing that this solves an important problem. The Platform Steering Group was in full support of this proposal. Therefore, SE-0482 has been accepted.
I'd like to thank the proposal authors and the reviewers for contributing to Swift.
Kuba Mracek, Review Manager
Great to see this proposal being accepted! I'm wondering if this feature is expected to land in Swift 6.2 , or do we have any rough timeline on when it might become available?
The implementation in SE-0482 are two PRs, one still in draft, but neither merged - and the release branch for 6.2 has already been cut.
I personally wouldn't expect to see this hit until at least Swift 6.3, and that's assuming that there aren't additional complications found during final implementation and merging all this into place.
There is this PR that has been merged so it might actually land in Swift 6.2.
Yes this is where we did the actual implementation, we never updated the proposal. It's going to be in 6.2 although the opt-in auditing tool has not been finalized.
I needed this feature so bad, so I looked up the forum, and here I am. I wanted to say that I’ve just tested it successfully with the latest 6.2 snapshot on Linux, I’ll try Windows next. Looking forward to the stable release, this is a game-changer. Thank you.
Great to hear that this is working for you on Linux. On Windows the implementation still needs a bit of work to handle static libraries on Windows correctly which is tracked in Add support for static libraries in binary targets · Issue #8657 · swiftlang/swift-package-manager · GitHub.
Yep, I’ve just stumbled upon it. A cosmetic thing I noticed so far, which I’m sure you’re aware of, is that SPM requires the “lib” prefix in say “libfoobar.lib”, but then lld-link looks for “foobar.lib”.
That’s interesting. We have the opposite problem with the swift-syntax prebuilts. SwiftPM generates libfoobar.a and the native linker, link.exe, wants the suffix to be .lib. lld-link is fine with .a. We’ll need to straighten out that story when we get closer to completing the –build-system swiftbuild transition.
It’s a bit more complicated than this. The current Windows behaviour is:
lib<name>.lib<name>lib<name>.dll<name>.dll<name>.lib<name>.libThat is, depending on what you are building and linking, you might want lib<name>.lib or you may want <name>.lib.