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" to install the 6.3.3 toolchain with:
swift run swift-sdk-generator make-linux-sdk \
--target aarch64-unknown-linux-gnu \
--distribution-name debian \
--distribution-version 13
swift experimental-sdk install /Users/<elided>/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:
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]
/Users/<elided>/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<CInterop.FTSEnt> {
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:
/Users/<elided>/repos/ccc/<elided>/.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.
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).
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:
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?
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). 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).
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:
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.
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):
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 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.
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.
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 (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, but that should have little effect on this import feature, which was enabled years ago).
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.
Quick update this. I received a response on #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:
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:
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?
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.
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).
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.
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. As far as I'm aware, use of dynamically linked Musl is not currently supported by Swift.
) or remove 