# Cross-compiling 6.3.3 for aarch64 debian 12 or 13 **URL:** \ **Category:** Embedded\ **Tags:** raspberrypi, swift-nio, swift-sdk\ **Created:** [August 1, 2026, 6:36pm UTC](https://forums.swift.org/t/cross-compiling-6-3-3-for-aarch64-debian-12-or-13/88700 "2026-08-01T18:36:35Z")\ **Posts on this page:** 17\ **Page:** 1
**Author:** ![cora](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/cora/32/46111_2.png) [@cora](https://forums.swift.org/u/cora)\ **Post date:** [August 1, 2026, 6:36pm UTC](https://forums.swift.org/t/cross-compiling-6-3-3-for-aarch64-debian-12-or-13/88700/1 "2026-08-01T18:36:35Z")
Apologies if I'm posting in the wrong spot; please feel free to redirect. I'm attempting to cross-compile from my mac (m1 max / osx 26.8), targeting an older raspberry pi (aarch64) running Debian 13 (Trixie). I'm able to follow @xtremekforever 's awesome instructions [at "Using Swift SDKs with Raspberry Pis"](https://xtremekforever.substack.com/p/using-swift-sdks-with-raspberry-pis) to install the 6.3.3 toolchain with: ```bash swift run swift-sdk-generator make-linux-sdk \ --target aarch64-unknown-linux-gnu \ --distribution-name debian \ --distribution-version 13 swift experimental-sdk install /Users//repos/misc/swift-sdk-generator/Bundles/6.3.3-RELEASE_debian_trixie_aarch64.artifactbundle ``` However, when I attempt to run the verification step, I compilation errors related to missing imports in NIO: ```bash git clone https://github.com/hummingbird-project/hummingbird-examples cd hummingbird-examples/hello/ swift build --swift-sdk 6.3.3-RELEASE_debian_trixie_aarch64 ``` [snip] ```txt /Users//repos/misc/hummingbird-examples/hello/.build/checkouts/swift-nio/Sources/_NIOFileSystem/DirectoryEntries.swift:751:47: error: property 'fts_path' is not available due to missing import of defining module '_FoundationCShims' [#MemberImportVisibility] 19 | import NIOPosix 20 | import SystemPackage 21 | | `- note: add import of module '_FoundationCShims' 22 | /// An `AsyncSequence` of entries in a directory. 23 | @available(macOS 10.15, iOS 13.0, watchOS 6.0, tvOS 13.0, *) : 749 | extension UnsafeMutablePointer { 750 | fileprivate var path: FilePath { 751 | FilePath(platformString: self.pointee.fts_path!) | `- error: property 'fts_path' is not available due to missing import of defining module '_FoundationCShims' [#MemberImportVisibility] 752 | } 753 | } ``` [/snip] I also tried compiling a Vapor toy that is what I eventually wish to deploy; it too fails in NIO, but complaining about different a different file and regarding different symbols: ```txt /Users//repos/ccc//.build/checkouts/swift-nio/Sources/_NIOFileSystem/FileInfo.swift:239:36: error: property 'st_nlink' is not available due to missing import of defining module 'CDispatch' [#MemberImportVisibility] 20 | @preconcurrency import Glibc 21 | import CNIOLinux 22 | #elseif canImport(Musl) | `- note: add import of module 'CDispatch' 23 | @preconcurrency import Musl 24 | import CNIOLinux : 237 | var isEqual = lStat.st_dev == rStat.st_dev 238 | isEqual = isEqual && lStat.st_mode == rStat.st_mode 239 | isEqual = isEqual && lStat.st_nlink == rStat.st_nlink | `- error: property 'st_nlink' is not available due to missing import of defining module 'CDispatch' [#MemberImportVisibility] 240 | isEqual = isEqual && lStat.st_ino == rStat.st_ino 241 | isEqual = isEqual && lStat.st_uid == rStat.st_uid ``` Any ideas? I'm not doing anything particularly fancy, and I don't think I'm missing any steps, but I probably am. Thanks! ---
**Author:** ![RandomHashTags](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/randomhashtags/32/24259_2.png) [@RandomHashTags](https://forums.swift.org/u/RandomHashTags)\ **Post date:** [August 1, 2026, 10:43pm UTC](https://forums.swift.org/t/cross-compiling-6-3-3-for-aarch64-debian-12-or-13/88700/2 "2026-08-01T22:43:17Z")
I'm pretty sure those are bugs in the projects since I also get similar errors on Arch Linux when compiling `hummingbird-examples/hello`. However, it compiles just fine (on my machine) without the `MemberImportVisibility` feature flag (from [SE-0444](https://github.com/swiftlang/swift-evolution/blob/main/proposals/0444-member-import-visibility.md)). ---
**Author:** ![cora](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/cora/32/46111_2.png) [@cora](https://forums.swift.org/u/cora)\ **Post date:** [August 2, 2026, 7:03am UTC](https://forums.swift.org/t/cross-compiling-6-3-3-for-aarch64-debian-12-or-13/88700/3 "2026-08-02T07:03:18Z")
Thanks @RandomHashTags . That doesn't seem to have any impact. In my toy project, the generated `Package.swift` contains a `var swiftSettings` which explicitly enables a bunch of flags, including `#MemberVisibility`: ```swift var swiftSettings: [SwiftSetting] { [ .enableUpcomingFeature("ExistentialAny"), .enableUpcomingFeature("InternalImportsByDefault"), // .enableUpcomingFeature("MemberImportVisibility"), .enableUpcomingFeature("InferIsolatedConformances"), .enableUpcomingFeature("ImmutableWeakCaptures"), ] } ``` As you can see, I've commented that line out; after scouring my tree for any stale artifacts (I think), the compiler behavior is unchanged. In `hummingbird/hello`, there is no explicitly-configured `[SwiftSetting]` value; I'm not sure if that means that all, none, or some default nonempty subset of features is enabled. However when I explicitly pass a `[]` or a non-empty array that doesn't include `.enableUpcomingFeature("MemberImportVisibility")`, I see the same failure. I have _not_ tried building this on a linux _host_, however. Are you compiling on and targeting Arch, or are you cross-compiling? Thanks! ---
**Author:** ![RandomHashTags](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/randomhashtags/32/24259_2.png) [@RandomHashTags](https://forums.swift.org/u/RandomHashTags)\ **Post date:** [August 2, 2026, 7:53am UTC](https://forums.swift.org/t/cross-compiling-6-3-3-for-aarch64-debian-12-or-13/88700/4 "2026-08-02T07:53:41Z")
You cannot _directly_ "disable" dependency compilation flags (`swift-nio` does use `MemberImportVisibility` but I can successfully compile it on my machine with no modifications [no hummingbird example]). I am compiling on an Arch Linux host, for my host, with no cross-compilation. There are multiple ways you could try avoiding the errors, the first that comes to my mind would be to fork the projects and manually add imports where necessary (you could even open PRs to patch them so everyone benefits 😉 ) or remove `MemberImportVisibility` usage if possible. All that said, I'm pretty sure your use case is unsupported since Swift only officially supports Debian 12 (at least according to its [debian installation](https://www.swift.org/install/linux/debian/)). It is also worth noting Debian's latest Swift toolchain is 6.0.3, and the `MemberImportVisibility` is a 6.1 feature. That's not to say it cannot work, because it definitely could if the code you want to run doesn't use platform specific compilation, which some projects do (including `swift-nio`). ---
**Author:** ![cora](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/cora/32/46111_2.png) [@cora](https://forums.swift.org/u/cora)\ **Post date:** [August 2, 2026, 9:16am UTC](https://forums.swift.org/t/cross-compiling-6-3-3-for-aarch64-debian-12-or-13/88700/5 "2026-08-02T09:16:25Z")
Ok, that's helpful, thanks! Regarding the debian version support, I was wondering about that, as all of the instructions I found for building a suitable SDK indicated either `6.0.3` (as in @xtremekforever 's case) or `6.0.2` in another post that I saw. However, when I attempt to specify the `swift-version` as a param to `make-linux-sdk`, regardless of version, the tool 404s trying to download the tarball: ```sh swift run swift-sdk-generator make-linux-sdk --swift-version 6.0.3 --target aarch64-unknown-linux-gnu --distribution-name debian --distribution-version 12 Building for debugging... [4 / 62] NIOHTTP1 Build complete! (2,72 seg) 2026-08-02T09:18:02+0100 info org.swift.swift-sdk-generator: [SwiftSDKGenerator] Downloading required toolchain packages... 2026-08-02T09:18:02+0100 info org.swift.swift-sdk-generator: remoteUrl=https://download.swift.org/swift-6.0.3/debian12-aarch64/swift-6.0.3/swift-6.0.3-debian12-aarch64.tar.gz [SwiftSDKGenerator] Downloading remote artifact not available in local cache Error: downloadFailed(https://download.swift.org/swift-6.0.3/debian12-aarch64/swift-6.0.3/swift-6.0.3-debian12-aarch64.tar.gz, "404 Not Found") ``` I haven't dug around to see if it's just that the archive tree has been reorganized and `swift-sdk-generator`'s knowledge is out of sync (strategically choosing the yak paths I explore). If I don't specify, then it seems `6.3.3` is selected automatically, and the sdk build succeeds. However, eliminating the debian version issue by using bookworm/12 has no impact upon behavior. Of course, my mental model of this could be completely wrong too. I'm picking some of this back up after a long hiatus amongst other stacks, so there are some holes in my knowledge. Regarding the fork recommendation, thanks, I'll take a look at that next. I was a bit hesitant to go that route, but if contributions here are welcome then I'm happy to pitch in where I can. ---
**Author:** ![cora](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/cora/32/46111_2.png) [@cora](https://forums.swift.org/u/cora)\ **Post date:** [August 2, 2026, 10:36am UTC](https://forums.swift.org/t/cross-compiling-6-3-3-for-aarch64-debian-12-or-13/88700/6 "2026-08-02T10:36:23Z")
Ok, I've cloned `swift-nio`, and my initial step of simply commenting out `Platform.swfit:647` caused `swfit-nio` to build successfully on the cross target (debian 12 / bookworm), while introducing no new noise I could see in the compiler output when targeting the host (macos 26.6): ```patch diff --git a/Package.swift b/Package.swift index 18af92a1..7114ae6c 100644 --- a/Package.swift +++ b/Package.swift @@ -644,7 +644,7 @@ for target in package.targets { case .regular, .test, .executable: var settings = target.swiftSettings ?? [] // https://github.com/swiftlang/swift-evolution/blob/main/proposals/0444-member-import-visibility.md - settings.append(.enableUpcomingFeature("MemberImportVisibility")) + // settings.append(.enableUpcomingFeature("MemberImportVisibility")) target.swiftSettings = settings case .macro, .plugin, .system, .binary: () // not applicable ``` I have filed [Issue #3688](https://github.com/apple/swift-nio/issues/3688) with the details; I haven't yet had a chance to actually _test_ the code either happy path or on the cross host, but I'll keep the ticket updated. ---
**Author:** ![cora](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/cora/32/46111_2.png) [@cora](https://forums.swift.org/u/cora)\ **Post date:** [August 2, 2026, 11:09am UTC](https://forums.swift.org/t/cross-compiling-6-3-3-for-aarch64-debian-12-or-13/88700/7 "2026-08-02T11:09:44Z")
Just a quick followup to stay in sync with the ticket; I've confirmed that the above patch results in a viable target binary. However, as the code is in the cross-repo settings block, probably not the best place to suggest a fix. ---
**Author:** ![xtremekforever](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/xtremekforever/32/43018_2.png) [@xtremekforever](https://forums.swift.org/u/xtremekforever)\ **Post date:** [August 2, 2026, 11:16am UTC](https://forums.swift.org/t/cross-compiling-6-3-3-for-aarch64-debian-12-or-13/88700/8 "2026-08-02T11:16:43Z")
Wow, all of this makes me think that they should test Swift SDKs more from the project CIs. I think they do test WASM but maybe having some common cross-compilation targets would also be useful perhaps, so that issues like these are caught instead of not seen. ---
**Author:** ![Finagolfin](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/finagolfin/32/34388_2.png) [@Finagolfin](https://forums.swift.org/u/Finagolfin)\ **Post date:** [August 2, 2026, 3:33pm UTC](https://forums.swift.org/t/cross-compiling-6-3-3-for-aarch64-debian-12-or-13/88700/9 "2026-08-02T15:33:42Z")
> [@xtremekforever](#): > > Wow, all of this makes me think that they should test Swift SDKs more from the project CIs. I think they do test WASM but maybe having some common cross-compilation targets would also be useful perhaps, so that issues like these are caught instead of not seen. NIO is regularly tested against the three official Swift SDK bundles, as looking at [any of their CI runs will show](https://github.com/apple/swift-nio/actions/runs/30740309494) (I see that they cross-compile with some old snapshot tags of some of those SDKs, which would be easily fixed by switching to [the official Swift Github workflows](https://github.com/swiftlang/github-workflows), but that should have little effect on this import feature, which was enabled years ago). This sounds like some peculiarity with the linux SDKs generated by the Swift SDK generator used here, which might be tested better if there were [an official workflow for Swift packages to use to cross-compile against those generated linux SDKs, which I don't see](https://github.com/search?q=repo%3Aswiftlang%2Fgithub-workflows%20generator&type=code). Since [you're an active contributor to that repo](https://github.com/swiftlang/swift-sdk-generator/graphs/contributors?all=1), maybe you can add one. 🙂 ---
**Author:** ![cora](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/cora/32/46111_2.png) [@cora](https://forums.swift.org/u/cora)\ **Post date:** [August 2, 2026, 4:34pm UTC](https://forums.swift.org/t/cross-compiling-6-3-3-for-aarch64-debian-12-or-13/88700/10 "2026-08-02T16:34:47Z")
Thanks for the feedback all. Automated coverage of host/target configs like this would be awesome, but I suspect if it's indeed missing then it's probably a little further out, so I'll selfishly advocate for this specific issue. I am happy to help with the remediation, but I need to fault in a lot more context than I currently have, so that's not going to happen immediately. I would like to verify that I've at least filed the ticket in the right spot. Currently, it's filed in the `swift-nio` repo. Is this appropriate, or should I move/dup it to `swift-sdk-generator`? Is there an individual I should tag on the ticket? Etc. I get that this use case might not be top of anyone's stack right now, but what I lack in current info I make up for in time available, so I'm happy to use this as an opportunity to actually be useful to the project if I can. ---
**Author:** ![cora](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/cora/32/46111_2.png) [@cora](https://forums.swift.org/u/cora)\ **Post date:** [August 3, 2026, 9:04am UTC](https://forums.swift.org/t/cross-compiling-6-3-3-for-aarch64-debian-12-or-13/88700/11 "2026-08-03T09:04:30Z")
Quick update this. I received a response on [#3688](https://github.com/apple/swift-nio/issues/3688) concurring that this was probably an SDK issue and requesting I file a ticket there, which I intend to do. However I also did a little more poking around, and found the following which may or may not be interesting. First, I created a new SDK, indicating `musl` in the triple rather than `gnu`: ```sh swift run swift-sdk-generator make-linux-sdk \ --target aarch64-unknown-linux-musl \ --distribution-name debian \ --distribution-version 12 \ --sdk-name 6.3.3-RELEASE_debian_bookworm_aarch64_musl ``` I then compiled both `hummingbird/hello` and my Vapor app with: ```sh swift build \ --swift-sdk 6.3.3-RELEASE_debian_bookworm_aarch64_musl --triple aarch64-unknown-linux-gnu --static-swift-stdlib -c release ``` (my Vapor app also had a `--product` but was otherwise identical). When I did this, everything compiled with `MemberImportVisibility` enabled, and the resulting binary happily started on my pi. So that's cool. But note that the triple still points to `*-gnu` instead of `*-musl`. The build fails using the `musl` sdk if either the triple is elided, or if `*-musl` is used. I'm sure there's a good reason for this under the hood; at the user interface level it's a little odd. Net-net seems to point the finger further away from NIO and closer to the SDK. In which repo shall I file it? ---
**Author:** ![cora](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/cora/32/46111_2.png) [@cora](https://forums.swift.org/u/cora)\ **Post date:** [August 3, 2026, 9:43am UTC](https://forums.swift.org/t/cross-compiling-6-3-3-for-aarch64-debian-12-or-13/88700/12 "2026-08-03T09:43:25Z")
Ok, I've closed the ticket on `swift-nio`, and added [#268: Build failure, unavailable glibc symbols unavailable when cross compiling for debian12/aarch64 target on macos host](https://github.com/swiftlang/swift-sdk-generator/issues/268) to [swift-sdk-generator](https://github.com/swiftlang/swift-sdk-generator). The workaround above (using the `musl`-based SDK) works for me for now... the oddness with the triple is just a minor stone in my inner pedant's shoe but seems to have no other impact. ---
**Author:** ![cora](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/cora/32/46111_2.png) [@cora](https://forums.swift.org/u/cora)\ **Post date:** [August 3, 2026, 8:21pm UTC](https://forums.swift.org/t/cross-compiling-6-3-3-for-aarch64-debian-12-or-13/88700/13 "2026-08-03T20:21:41Z")
Not sure why I can't edit the issue body itself, but important update. At @xtremekforever 's request I attempted to repro this using the 6.3.3 open-source toolchain (as installed via swiftly), and it does _not_ reproduce. So this seems to be related to the toolchain shipping in the Xcode 27 beta, which I don't think I indicated clearly enough in the ticket (and not at all in this post). ---
**Author:** ![Finagolfin](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/finagolfin/32/34388_2.png) [@Finagolfin](https://forums.swift.org/u/Finagolfin)\ **Post date:** [August 4, 2026, 2:04am UTC](https://forums.swift.org/t/cross-compiling-6-3-3-for-aarch64-debian-12-or-13/88700/14 "2026-08-04T02:04:25Z")
Cross-compiling to other non-Darwin platforms with the Xcode toolchain is unsupported, to my knowledge. ---
**Author:** ![cora](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/cora/32/46111_2.png) [@cora](https://forums.swift.org/u/cora)\ **Post date:** [August 4, 2026, 7:11am UTC](https://forums.swift.org/t/cross-compiling-6-3-3-for-aarch64-debian-12-or-13/88700/15 "2026-08-04T07:11:21Z")
Yeah, that makes sense. I didn't see that noted anywhere and honestly didn't give it much thought at the time, but now that I understand how the ecosystem has evolved this is completely unsurprising. Apologies for the goose chase. ---
**Author:** ![Max\_Desiatov](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/max_desiatov/32/20654_2.png) [@Max\_Desiatov](https://forums.swift.org/u/Max_Desiatov)\ **Post date:** [August 4, 2026, 2:04pm UTC](https://forums.swift.org/t/cross-compiling-6-3-3-for-aarch64-debian-12-or-13/88700/16 "2026-08-04T14:04:11Z")
> [@cora](#): > > First, I created a new SDK, indicating `musl` in the triple rather than `gnu`: > > ```swift > swift run swift-sdk-generator make-linux-sdk \ > --target aarch64-unknown-linux-musl \ > --distribution-name debian \ > --distribution-version 12 \ > --sdk-name 6.3.3-RELEASE_debian_bookworm_aarch64_musl > > ``` Debian is not a Musl-based distribution, so I'm inclined to think that in such cases the generator should emit an error with a diagnostic message explaining that? If you'd like to cross-compile with statically linked Musl, please use [Static Linux Swift SDK](https://www.swift.org/documentation/articles/static-linux-getting-started.html). As far as I'm aware, use of dynamically linked Musl is not currently supported by Swift. ---
**Author:** ![cora](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/cora/32/46111_2.png) [@cora](https://forums.swift.org/u/cora)\ **Post date:** [August 4, 2026, 2:30pm UTC](https://forums.swift.org/t/cross-compiling-6-3-3-for-aarch64-debian-12-or-13/88700/17 "2026-08-04T14:30:27Z")
Thanks for catching that, @Max_Desiatov ; odd that that ended up producing a viable binary in that case, but will keep that in mind.