Support for x86_64 Macs?

[saromleang]

Attempting to install view Homebrew on an Intel-based MBP. I get the following on:

% sudo usbipd install-system-extension
Password:
sudo: unable to execute /usr/local/bin/usbipd: Bad CPU type in executable

[beriberikix]

Confirmed, and thank you for the clear report — Bad CPU type in executable is exactly right. The published binaries are arm64 only:

$ file usbipd-v0.5.1-macos
usbipd-v0.5.1-macos: Mach-O 64-bit executable arm64

The release workflow runs plain swift build --configuration release, which builds for the runner's architecture, and the runner is Apple silicon. So there has never been an x86_64 build — the install succeeds and the binary simply cannot execute.

The good news is that this is straightforward. I verified a universal build works on this project today:

$ swift build --configuration release --arch arm64 --arch x86_64 --product usbipd
$ lipo -archs .build/apple/Products/Release/usbipd
x86_64 arm64

It runs and reports the right version. The artifact lands in .build/apple/Products/Release/ rather than .build/release/, which is the one wrinkle for the packaging step. Cost is size — 10.8 MB universal against 5.6 MB arm64-only.

One caveat worth setting expectations on before you invest time: the note about sudo usbipd install-system-extension in your report is from an older release. That command has been removed, because it could not succeed from a Homebrew prefix — OSSystemExtensionRequest resolves extensions inside the calling app's bundle and requires it to live in /Applications. No System Extension is needed for the devices this can serve.

What it can serve is also narrower than the README used to imply: devices macOS has not bound a driver to — debug probes, boards in DFU mode, Android in ADB mode. Anything macOS claims (USB-serial, HID, mass storage, audio, cameras) is refused up front, and that is not fixable without a DriverKit entitlement Apple has so far declined. So a universal build will get usbipd running on your Intel Mac, but please check your target device is in the first category before counting on it — usbipd list then usbipd bind <busid> will tell you immediately.

[beriberikix]

Fixed in v0.5.2, just released.

The release now publishes one binary per architecture rather than a single arm64 one:

usbipd-v0.5.2-macos-arm64    (arm64,  signed)
usbipd-v0.5.2-macos-x86_64   (x86_64, signed)

The formula selects between them with on_arm/on_intel, so you download one artifact of about 5.4 MB. I went this way rather than shipping a universal binary because that would have doubled the download for every Apple silicon user to serve Intel — this way each architecture gets a slice that is actually slightly smaller than the old arm64-only build.

To install or upgrade:

brew update
brew upgrade usbip

# or, fresh:
brew tap beriberikix/usbipd-mac
brew trust beriberikix/usbipd-mac   # Homebrew 6 requires this for third-party taps
brew install usbip

I do not have an Intel Mac to test on, so I have verified what I can: the published x86_64 artifact reports Mach-O 64-bit executable x86_64, carries a Developer ID signature (TeamIdentifier=592A3U6J26), and the formula's on_intel branch points at it with a checksum matching the release. On Apple silicon the equivalent path is confirmed working end to end — installed via Homebrew, control and bulk transfers against a J-Link, and probe-rs driving that probe from a Linux client over USB/IP.

If you would let me know whether it runs on your MBP, I would appreciate it — that is the one step I cannot do myself. And if it launches but a device you care about is refused, usbipd bind will name the driver holding it; that is a separate limitation covered in #33.