Xcode 12.2 SPM: Swift-NIO Fails to Build for Apple Silicon (arm64)

Hi everyone. I rely on Swift-NIO installed via the Swift Package Manager (in Xcode 12.2 running on macOS Big Sur 11.0.1). I am attempting to build on a new M1 Mac and Xcode is reporting that it can't find an arm64 architecture for Swift-NIO:

Since the packages are built automatically when Xcode downloads them, I'm assuming the arm64 architecture hasn't been added to the build process yet? Is there an issue tracking that or a problem preventing it?

Thanks!

The forum wouldn't let me post two images because I'm a "new user", so here's the second image I would have posted showing the packages I have installed:

SwiftNIO is shipped as source-only: we don’t ship binaries. Our source supports arm64, but whether or not the arm64 version is available is not up to us: your software needs to build it locally.

How is your build system set up? Are you targetting both architectures? It may be worth clearing out your DerivedData folder and performing a complete rebuild.

That's what has me confused. I assumed the packages would be built using the same settings as my project, which are the standard architectures:

It seems like the package is only being built for x86_64, however. I'm new to using SPM in Xcode, so I'm wondering if there's something in the package.swift file that would override my project's build settings? What would cause the arm64 versions to not be built?

I've tried a clean build and I've also tried clearing the package manager's cache (Xcode has a command to do so in the File menu). Neither of those solved the issue.

CC @NeoNacho

Yes, but on the M1 Macs if you set to build the active architecture only and your app doesn’t have universal versions of all libraries, Xcode will build x86_64 and then run it through Rosetta. That’s what happens if I change that setting, because Xcode isn’t finding an arm64 version of Swift-NIO.

-Bryan

That shouldn’t matter, as NIO is built from source for the native arch. Building only for the active arch should ensure that all of your dependencies are only built for arm64.

I should note that I’ve been building SwiftNIO for months on the DTK, so unless this has regressed in Xcode 12.2, it should work fine.

Ok, I’ll give that a shot, but....eventually I need to build ALL architectures to ship a Universal binary, so this setting will end up being YES when I flip over to the release configuration and I’d expect to see the same error?

-Bryan

No, you’d ship a universal binary in your Release configuration, which should build for all platforms.

Correct, but shouldn’t I be able to build for all platforms in a debug configuration as well? What would stop Swift-NIO from being built for arm64 in a debug configuration?

-Bryan

This seem to be working as expected on my DTK with Xcode 12.2 with a Vapor project, including universal Release binaries. So I think this is either a regression on real M1 systems, or something more particular to your project.

I’ll try a completely fresh project and add Swift-NIO as a package and see what I get. I’ll be back at my Mac in a couple hours.

Okay, I've been able to reproduce the issue with a completely fresh project. I recorded a 3-minute screencast walking through the process and showing exactly what I'm doing: https://www.youtube.com/watch?v=M0iTmJblJns

If the "Build Active Architectures Only" option is set to NO for the Debug configuration, Swift-NIO fails to build correctly (one of the two architectures is always missing—which one seems random).

I'm not sure if this is an Xcode issue or if there's another setting somewhere that would cause this behavior in Debug, but it seems like Swift packages should build correctly regardless of the "build active architecture only" value.

I have not attempted to reproduce this with any other Swift package. Perhaps that would be the next step?

Are you using an Xcode project which integrates NIO, or operating on a Package which uses NIO? My project is Package based, so that may be the difference.

I'm simply creating a new Mac app, adding Swift-NIO as a package using Xcode's interface, then adding import NIO to the top of the AppDelegate.swift file.

In the screencast, I clear the package cache and perform a clean build. Neither solves the issue.

Seems like an Xcode bug then, not NIO.

I agree. Are you able to reproduce it, following the screencast? If so, I'll file a radar.

When I set "Build Active Architecture Only" option to YES in Debug, I still get an Intel build running through Rosetta.

I'm just going to have to compile the framework to a library myself instead of relying on the Swift Package Manager. SPM has been nothing but a headache every time I've tried it.

Terms of Service

Privacy Policy

Cookie Policy