Skip to content

[stdlib] Back out recent Musl changes for output/input streams - #91064

Merged
finagolfin merged 1 commit into
swiftlang:mainfrom
finagolfin:musl
Jul 30, 2026
Merged

finagolfin merged 1 commit into
swiftlang:mainfrom
finagolfin:musl

Conversation

@finagolfin

Copy link
Copy Markdown
Member

Recent pulls #89891 and #90679 tried to improve the async typing for Musl but broke the static linux SDK CI, so temporarily reverting.

@finagolfin
finagolfin requested a review from a team as a code owner July 29, 2026 14:33
Recent pulls swiftlang#89891 and swiftlang#90679 tried to improve the async typing for Musl
but broke the static linux SDK CI, so temporarily reverting.
@finagolfin

Copy link
Copy Markdown
Member Author

Temporarily backing out this change to get static linux SDK CI green till @JacobHearst, @ktoso, and @al45tair can figure out a fix. The new test they added built fine locally anyway with the last July 11 trunk snapshot of the static linux SDK, but this is where a static linux PR CI would really come in handy, @justice-adams-apple.

@swift-ci smoke test

@finagolfin

finagolfin commented Jul 30, 2026 •

Copy link
Copy Markdown
Member Author

Merging this Musl revert to try and get trunk static linux SDK CI unblocked, though unsure if this will work. 🤞

@finagolfin
finagolfin merged commit 500e2bd into swiftlang:main Jul 30, 2026
3 checks passed
@finagolfin

Copy link
Copy Markdown
Member Author

Oh nice, this revert fixed the trunk static linux SDK CI for now, will let you guys hash out how to bring this change back.

@finagolfin
finagolfin deleted the musl branch July 30, 2026 13:05
@JacobHearst

Copy link
Copy Markdown
Contributor

@finagolfin is there a good way for me to reproduce these CI builds locally? Or failing that is there a way to manually trigger the static sdk builds for a specific PR?

@finagolfin

Copy link
Copy Markdown
Member Author

Locally, you can use the same Docker setup the CI uses, but there is currently no way to manually trigger that on the CI (I have asked the CI team about setting that up and will let you know what they say, but that may take awhile, so better to try locally).

@JacobHearst

JacobHearst commented Aug 6, 2026 •

Copy link
Copy Markdown
Contributor

I'm getting a bit lost here in the nuances of the various libc implementations and how that factors into the static linux SDK but I think Musl and WASI actually didn't need any changes at all?

Both Musl and WASI declare stdin/out/err as extern FILE *const which comes into Swift as a let so they don't have any sendability issues.

I tested both locally on my macOS machine with a tiny SPM package and Swift 6.3.3's static linux sdk:

Package.swift

// swift-tools-version: 6.3.3
import PackageDescription

let package = Package(
    name: "HelloWorld",
    targets: [
        .executableTarget(
            name: "HelloWorld",
            swiftSettings: [.swiftLanguageMode(.v6)]
        )
    ],
    swiftLanguageModes: [.v6],
)

main.swift

import Foundation
fputs("Hello world", stderr)

Build Musl: rm -rf .build && swift build --swift-sdk swift-6.3.3-RELEASE_static-linux-0.1.0
Build WASI: rm -rf .build && swift build --swift-sdk swift-6.3.3-RELEASE_wasm

@finagolfin

Copy link
Copy Markdown
Member Author

@ktoso, wdyt? I'll note that I expected the test you all added to fail for Musl after I backed this out, but as I noted last week, it didn't.

@finagolfin

Copy link
Copy Markdown
Member Author

@JacobHearst, if you can try enabling Konrad's test for the remaining platforms, as we discussed last month, we can discuss any further changes like this needed on a pull you submit.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants