Add Static Linux Swift SDK support for cross-compilation by adincebic · Pull Request #1813 · bazelbuild/rules_swift

adincebic · 2026-06-16T12:49:38Z

Adding a new swift.static_linux_sdk(...) module extension tag, which downloads the Static Linux SDK artifact bundle from swift.org, generates matching Swift and C/C++ toolchains for x86_64-swift-linux-musl and aarch64-swift-linux-musl, and
wires those toolchains into the existing standalone-toolchain flow.

I am also adding a dedicated //swift/toolchains:static_linux constraint to distinguish Static Linux targets from generic Linux targets. Further more, I tried documenting Static Linux SDK setup and toolchain registration

One important detail is toolchain registration order: Static Linux SDK toolchains must be registered before generic Linux Swift toolchains, since both are compatible with @platforms//os:linux and Bazel prefers earlier registered toolchains. Open to discussing if there is a better way to do this.

cerisier · 2026-06-17T12:43:16Z

+        # `swiftc` defaults to it, `swift-symbolgraph-extract` (used for XCTest
+        # test discovery) matches the module layout's triple exactly and fails
+        # to load modules built for `*-windows-msvc` if it is omitted.
+        return "%s-unknown-windows-msvc" % arch


What are the other windows target triples supported by swiftc ?

cerisier · 2026-06-17T12:51:32Z

+it cannot target by itself. The `swift` extension can download these and
+define matching Swift and C/C++ toolchains, so that plain `swift_library`


Should you make this opt-out to allow c/c++ toolchains to be registered by a different module ?

cerisier · 2026-06-17T12:55:23Z

+
+filegroup(
+    name = "sdk_files",
+    srcs = glob(["{bundle_dir}/**"]),


Should you use source directories ?

cerisier · 2026-06-17T13:01:28Z

+)
+
+constraint_value(
+    name = "static_linux",


If static_linux really implies musl, I would model that using libc semantic. That way everything will align when bazel-contrib/platforms_contrib#5 lands.

+1. and if you want you can reuse @llvm's libc/musl constraint for now, that is what rules_rs does as well. Once platforms_contrib ships, we will make ours a forwarding alias

it does imply musl, but maybe the problem is you "can't" just use any old musl cc toolchain, since apple's clang fork that ships with swift is tied to who knows what implementation details. so that probably still means we need some custom constraint like this? (and maybe should also add the musl constraint for random select() statements)

dzbarsky · 2026-06-19T14:03:08Z

+
+  * a `swift_toolchain` that compiles against the SDK's sysroot and Swift
+    resource directory, and links against its static Swift runtime; and
+  * a rules_cc `cc_toolchain` that drives the matching clang for the target


is it possible to reuse existing cc toolchain like hermetic-llvm? I feel like otherwise there will be a lot of duplicated clang binaries in the output base and more maintenance burden overall. We already support wasm, happy to look at what's missing to make android work better

So the problem I think is that unless those are used for exec tools, the LLVM version used by Apple Clang is that of their own and mismatch means either failures or no LTO

dzbarsky · 2026-06-19T14:04:24Z

+_HOST_LINKER_INPUTS = "swift_sdk_linker_inputs"
+
+_CC_TOOLCHAIN_TEMPLATE = """
+cc_tool(


i think a lot of this could be cleaner if it was an actual .bzl file that had a macro to stamp out these targets and this .bzl emitted a load to it. would make LSPs less confused

dzbarsky · 2026-06-19T14:05:41Z

+        triple = "wasm32-unknown-wasip1",
+    )
+
+    repository_ctx.file("BUILD.bazel", build_content)


please make sure you mark all repo rules and module extensions reproducible = True as appropriate!

dzbarsky · 2026-06-19T14:07:10Z

+            doc = "The Android API level to target.",
+            mandatory = True,
+        ),
+        "host_swiftc": attr.label(


do you actually need to pass this or can you just construct the label yourself? (repo rule can fabricate labels). That's how rules_rs deals with host_cargo

dzbarsky · 2026-06-19T14:08:33Z

+        )
+    return content
+
+def static_linux_sdk_toolchains_for_platform(platform, sdk_repository, archs):


does this mean you are duplicating all the SDK bytes just to change the target to musl? Or is it reusing the tools but only emitting new toolchain targets? (Finding it a bit hard to trace what is materialized where, the way this is written)

dzbarsky · 2026-06-19T14:09:39Z

        ]),
    )

+def _python_executable_works(repository_ctx, python_bin):


shouldn't we be using the python toolchain? this seems pretty hacky (though I see its partially preexisting)

dzbarsky · 2026-06-19T14:12:11Z

    if os == "linux":
        return "%s-unknown-linux-gnu" % arch
+    elif os == "windows":
+        # The MSVC cc toolchain reports a `target_gnu_system_name` of "local",


what is the "MSVC cc toolchain", do you mean the default one created by rules_cc? What about hermetic ones like @llvm? this feels like it's baking in a lot of assumptions about other toolchains?

keith · 2026-06-23T14:51:54Z

I'll review this one once logan's stuff is in!

keith

still reviewing but flushing some comments

keith · 2026-07-08T18:14:18Z

+toolchain_static_linux_x86_64_test = make_action_command_line_test_rule(
+    config_settings = {
+        "//command_line_option:extra_toolchains": [
+            "//test/fixtures/toolchains:cc_toolchain_static_linux_x86_64",
+            "//test/fixtures/toolchains:toolchain_static_linux_x86_64",
+        ],
+    },
+)


can we use the real toolchain we're registering for this instead of creating some fake ones? this doesn't prove much since we're just testing the behavior of the copy pasted fixture AFAIUI?

keith · 2026-07-08T18:28:48Z

+def _static_linux_resource_path(target_settings, triple):
+    resource_path = target_settings.get("swiftStaticResourcesPath")
+    field = "swiftStaticResourcesPath"
+    if not resource_path:
+        resource_path = target_settings.get("swiftResourcesPath")
+        field = "swiftResourcesPath"
+    return _relative_metadata_path(resource_path, field, triple)


when doesn't it include swiftStaticResourcesPath?

Well it actually includes it every time at least starting from Swift 6.3.2. However since both swiftStaticResourcesPath and swiftResourcesPath are present in swift-sdk.json I first check for the swiftStaticResourcesPath and fall back to the swiftResourcesPath

{ "schemaVersion": "4.0", "targetTriples": { "x86_64-swift-linux-musl": { "toolsetPaths": [ "toolset.json" ], "sdkRootPath": "musl-1.2.5.sdk/x86_64", "swiftResourcesPath": "musl-1.2.5.sdk/x86_64/usr/lib/swift_static", "swiftStaticResourcesPath": "musl-1.2.5.sdk/x86_64/usr/lib/swift_static" }, "aarch64-swift-linux-musl": { "toolsetPaths": [ "toolset.json" ], "sdkRootPath": "musl-1.2.5.sdk/aarch64", "swiftResourcesPath": "musl-1.2.5.sdk/aarch64/usr/lib/swift_static", "swiftStaticResourcesPath": "musl-1.2.5.sdk/aarch64/usr/lib/swift_static" } } }

Ok I downloaded some of the older ones and all of them have the same shape, so I am dropping the swiftResourcesPath since it has the same value as swiftStaticResourcesPath anyway.

keith · 2026-07-08T18:33:06Z

+    linker_arg_expected = False
+    for arg in args:
+        if linker_arg_expected:
+            if arg.startswith("-undefined=") and arg != "-undefined=":
+                linkopts.append("-Wl,-u," + arg.removeprefix("-undefined="))
+            else:
+                linkopts.extend(["-Xlinker", arg])
+            linker_arg_expected = False
+        elif arg == "-Xlinker":
+            linker_arg_expected = True
+        else:
+            linkopts.append(arg)
+
+    if linker_arg_expected:
+        linkopts.append("-Xlinker")


why are we processing these? why not take them as they are in the file?

Because we can't just take the contents as is:

-static -lswiftCore -lswift_RegexParser -Xlinker -undefined=pthread_self -Xlinker -undefined=pthread_once -Xlinker -undefined=pthread_key_create -ldispatch -lBlocksRuntime -lpthread -ldl -lc++ -lm

purely because of -Xlinker flags.

you can remove this after #1839

Perfect. Removed.

keith · 2026-07-08T18:34:50Z

+        linux_static_dir_relative,
+        repo_root):
+    swiftrt_relative = "{}/{}/swiftrt.o".format(linux_static_dir_relative, arch)
+    args_relative = linux_static_dir_relative + "/static-executable-args.lnk"


what is the difference between this one and the static-stdlib-args.lnk? looks like the args aren't 1:1, so maybe we need some combo? fwiw for android and wasm we didn't fetch from this file we hardcoded the args instead. this is probably a bit nicer for when new ones are introduced, assuming that all these args make sense in bazel.

static-stdlib-args.lnk is for the case where you want to statically link Swift standard library swiftc -static-stdlib which we don't need here, at least not yet.

Also those flags that come from static-executable-args.lnk seem to make sense with Bazel unless I am missing something. I wouldn't like us to hardcode them if we don't have to.

keith · 2026-07-08T18:43:23Z

+)
+
+constraint_value(
+    name = "static_linux",


it does imply musl, but maybe the problem is you "can't" just use any old musl cc toolchain, since apple's clang fork that ships with swift is tied to who knows what implementation details. so that probably still means we need some custom constraint like this? (and maybe should also add the musl constraint for random select() statements)

keith · 2026-07-08T18:53:10Z

+platform(
+    name = "static-linux-x86_64",
+    constraint_values = [
+        "@platforms//cpu:x86_64",
+        "@platforms//os:linux",
+        "//swift/toolchains:static_linux",
+    ],
+)


if this is something we end up requiring, we should move this somewhere that users can reference it too

Probably at the root?

adincebic requested review from aaronsky, brentleyjones, keith, luispadron and mattrobmattrob as code owners June 16, 2026 12:49

adincebic force-pushed the adin/crosscompile-linux branch from 8d7f3be to 7ae62ec Compare June 16, 2026 13:33

cerisier reviewed Jun 17, 2026

View reviewed changes

dzbarsky reviewed Jun 19, 2026

View reviewed changes

Comment thread swift/internal/extensions/swift_sdk_releases.bzl Outdated

dzbarsky reviewed Jun 19, 2026

View reviewed changes

Comment thread MODULE.bazel

keith added this to the 4.0.0 milestone Jun 23, 2026

This was referenced Jun 23, 2026

Support cross-compiling to WebAssembly with a Swift SDK #1817

Merged

Support cross-compiling to Android with a Swift SDK #1818

Merged

Build and test Swift natively on a Windows host #1819

Merged

adincebic force-pushed the adin/crosscompile-linux branch from 7ae62ec to eaad696 Compare July 8, 2026 06:19

keith reviewed Jul 8, 2026

View reviewed changes

adincebic force-pushed the adin/crosscompile-linux branch from da7fa11 to 1984608 Compare July 9, 2026 08:35

adincebic added 3 commits July 10, 2026 15:22

Cross compile to Linux

9a6d29c

read linker args from SDK file

a1fea1f

Use real toolchain in tests

5ccdb15

remove

e166267

adincebic force-pushed the adin/crosscompile-linux branch from 1984608 to e166267 Compare July 10, 2026 13:37

		it cannot target by itself. The `swift` extension can download these and
		define matching Swift and C/C++ toolchains, so that plain `swift_library`

Uh oh!

Conversation

adincebic commented Jun 16, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

keith commented Jun 23, 2026

Uh oh!

keith left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

adincebic Jul 9, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

adincebic commented Jun 16, 2026 •

edited

Loading

adincebic Jul 9, 2026 •

edited

Loading