Multiple Swift SDKS match ID '...' (without supposed duplicate installed)

Using Swift
1

I have installed the Swift Android SDK as per Getting Started with the Swift SDK for Android.

When I build my project with swift build --product CounterExample --swift-sdk aarch64-unknown-linux-android28, it builds fine without warnings, but if I instead build it with --swift-sdk swift-6.3-DEVELOPMENT-SNAPSHOT-2026-01-09-a_android --triple aarch64-unknown-linux-android28 I get the following warning printed 26 times in a row;

warning: multiple Swift SDKs match ID swift-6.3-DEVELOPMENT-SNAPSHOT-2026-01-09-a_android and host triple arm64-apple-macosx15.0, selected one at /Users/stackotter/Library/org.swift.swiftpm/swift-sdks/swift-6.3-DEVELOPMENT-SNAPSHOT-2026-01-09-a_android.artifactbundle/swift-android

I’m perplexed by the warning because I cannot find a duplicate SDK anywhere, and I don’t get the warning when I use an installed WASM SDK by identifier.

$ swift sdk list
5.10-SNAPSHOT-2024-04-09-a-wasm
swift-6.3-DEVELOPMENT-SNAPSHOT-2026-01-09-a_android

$ ls ~/Library/org.swift.swiftpm/swift-sdks
swift-6.3-DEVELOPMENT-SNAPSHOT-2026-01-09-a_android.artifactbundle
swift-wasm-5.10-SNAPSHOT-2024-04-09-a-macos_arm64.artifactbundle

$ readlink ~/.swiftpm/swift-sdks
/Users/stackotter/Library/org.swift.swiftpm/swift-sdks

My installed Swift Android SDK only defines a single SDK artifact with a single variant;

{
  "schemaVersion": "1.0",
  "artifacts": {
    "swift-6.3-DEVELOPMENT-SNAPSHOT-2026-01-09-a_android": {
      "variants": [
        {
          "path": "swift-android"
        }
      ],
      "version": "0.1",
      "type": "swiftSDK"
    }
  }
}

Are there other SDK installation locations that I should know about?

The reason that I’d like to directly specify the SDK to use rather than the triple to search for is that I’m working on Android support for Swift Bundler, and I read that specifying an SDK by triple only works if there’s exactly one SDK installed that supports the specified triple. To be resilient against having multiple SDKs installed, Swift Bundler will have to specify the SDK by identifier instead of target triple.

1 Like
2

On a related note, if an SDK’s artifactbundle defines multiple swiftSDK artifacts or a swiftSDK artifact with multiple variants, how are the artifacts/variants disambiguated from one another? It seems like SwiftPM only lets you specify the artifactbundle, then it’s up to SwiftPM to select the right SDK within the artifactbundle, which means that tools such as Swift Bundler that parse Swift SDK metadata have to keep SDKs grouped together, and that they can’t know ahead of time which variant is going to be selected.

Existing SDKs generally seem to have a single artifact and a single variant, but I’d rather that my code doesn’t make bad assumptions about the structure of such a flexible format if it doesn’t have to.

EDIT: Nevermind, I confused variants and artifacts. The artifact identifier is indeed what gets used to uniquely identify SDKs. I assume that they are only intended to be multiple variants present when their supportedTriples do not overlap?

3

Yes, the SDK bundle feature never supported such disambiguation using --triple that you are attempting.

I have looked into it and hope to add that soon.

4

In this case I’m not attempting to disambiguate using triple because there is only one Android SDK installed on my system and it only has a single artifact with a single variant. I only added the triple to properly target my intended target platform. In the ambiguity warning it says that the option that it decided on was `~/Library/org.swift.swiftpm/swift-sdks/swift-6.3-DEVELOPMENT-SNAPSHOT-2026-01-09-a_android.artifactbundle/swift-android` so I assumed that the warning didn’t have anything to do with ambiguity between triples (as that path is before it decides triples).

In my case, it resolved to exactly the SDK I would have expected; I’m just confused why it thinks that there are multiple.

5

Not sure about the many warnings, but when you simply choose an SDK like that using --swift-sdk, instead of specifying a triple using --swift-sdk, it will randomly choose a triple from that SDK for you, as one of the issues linked from that issue I gave you shows, ie the --triple you gave is not correctly applied. So it is useless to specify the SDK with --swift-sdk unless it only provides a single target triple, which even the static linux SDK does not.

1 Like
6

Ah ok, I misunderstood what you meant by disambiguation because I thought that you were referring to the ambiguity warning. Your response makes sense now, and I hope that the issue gets fixed :crossed_fingers: I will probably have time to look into it once I’ve got some basic Android support working (if no one else has gotten to fixing the issue yet).

Is there any workaround to use a specific SDK while also correctly compiling for the target triple? I guess worst case scenario I could synthesise the -sdk, -resource-dir and -Xcc --sysroot arguments that SwiftPM passes to its frontend invocations myself, but that doesn’t feel ideal for forward compatibility with future SwiftPM versions that may generate those arguments differently.

7

No, right now, you must simply make sure that the triple you want is only provided by one of your installed SDKs and just use --swift-sdk <target-triple> exclusively, as that is the only approach guaranteed to work.

8

I’ve opened a draft PR with a fix that seems to work on my machine; Fix Swift SDK triple handling by stackotter · Pull Request #9658 · swiftlang/swift-package-manager · GitHub

I’ve updated the SDK resolution logic to not just ignore --triple when --swift-sdk is present.

It’s late at night so I haven’t tested in-depth yet, but it does seem to work as I would expect.

9

I have figured out a workaround for this issue in Swift Bundler that I find satisfactory. Swift Bundler locates a suitable SDK itself when --platform android is passed to it (like I already wanted to do), and then it creates a temporary directory containing only a symlink to the desired sdk, and passes --swift-sdks-path /path/to/temp/directory --swift-sdk <target triple> to SwiftPM to use the SDK. The temporary directories are reused where possible. This solution should be forwards compatible with future SwiftPM versions as well as long as support for target triples as SDK identifiers doesn’t get removed without a suitable deprecation timeline.

1 Like