Macos/host support - #10087
Conversation
${var:0:-1} (negative substring length) and ${var,,} (lowercase expansion) are
bash 4 features. macOS still ships bash 3.2, where both are syntax errors, so
configure.sh cannot run there at all.
Replace them with equivalents that work on both.
Signed-off-by: Nat Brown <natbro@gmail.com>
--target-arch selects the SDK image but nothing tells the container engine which platform to run it as, so it only works when the host is already native for the target. Building arm64 on an x86_64 host, or x86_64 on an arm64 host, either fails or silently depends on the engine guessing. Derive the platform from the target architecture and pass --platform when the host is not native for it, both when probing the engine and in the options used for the build itself. Same-architecture builds pass nothing, as before. Signed-off-by: Nat Brown <natbro@gmail.com>
Three things a macOS host needs that a Linux host does not: - Rosetta. An x86_64 container on Apple Silicon must be translated by Rosetta rather than QEMU or the build does not work; check for it, but only when we are actually running an amd64 container on an arm64 host. - /etc/machine-id. Neither Docker nor Podman provide one on macOS and Wine requires it, so generate one and bind mount it. - MAKE. macOS resolves make to a path inside Xcode which does not exist in the container, so record an explicit /usr/bin/make in the generated Makefile. Also fail early if kern.maxfiles is too low; the default is well below what rsync and the source setup stages need, and the resulting failures are opaque. Signed-off-by: Nat Brown <natbro@gmail.com>
test-container proves the container runs, but there is no supported way to get a shell inside it with the same mounts and working directory the build uses. That is the quickest way to reproduce a failing build step by hand. Signed-off-by: Nat Brown <natbro@gmail.com>
Covers the host prerequisites enforced by configure.sh: Rosetta 2 on Apple Silicon, the raised file handle limit, and the fact that Proton itself does not run on macOS. Signed-off-by: Nat Brown <natbro@gmail.com>
|
While I can appreciate the effort you've taken here, it's difficult to advocate for any solution that depends on Rosetta 2 knowing in advance that it's already being phased out (https://support.apple.com/en-us/102527). |
|
I can understand the concern and sentiment. Technically Apple's statement is about Rosetta 2 being phased out for running general purpose x86_64 macOS apps with a special exception set aside for games (so existing native macOS x86_64 games will keep running for a bit), as well as development using the Game Porting Toolkit. Not yet stated by Apple but expected by Docker and RedHat/Podman in their roadmaps is that Apple's Virtualization Framework will continue to provide translation for x86 container workloads. That said, this PR has only a small Rosetta check and other changes are more about cross-container building - if Rosetta does disappear for virtualization the changes would still be useful for building arm64 targets in an arm64 container. |
|
Upon further spelunking, Apple actually has noted virtualization no longer requires Rosetta and is handled natively. see https://developer.apple.com/documentation/virtualization/running-intel-binaries-in-linux-vms - "macOS 27 directly integrates support for Intel binary translation, without needing to install Rosetta." So, this use case is not halted by Rosetta's end-of-life. |
|
Hi @kisak-valve The scenario described in this PR utilizes the Virtualization frameworks capability to translate intel binaries within a linux virtual machine. As noted by @natbro, this capability is now built into the system and no longer requires Rosetta be installed to operate. This capability is distinct from the deprecation of Rosetta for Intel-based macOS binaries. |
3 participants
This PR adds support for building x86 and arm64 Proton from a macOS host using Docker or Podman utilizing the Apple Virtualization Framework and Rosetta 2. A developer might like this support because between the SSD speeds and the large number of high-speed cores, Apple Silicon Macs build Proton very quickly, yielding faster iteration of builds and testing.
With these changes, arm64 Proton builds completely through redist and creates an entire default prefix. The x86 Proton build will fail to finalize the redist and prefix unless the minor proton-wine changes proposed in ValveSoftware/wine#350 are applied. These changes will soon be pending a merge request and review with Wine maintainers upstream.
This set of mostly-independent commits fix minor portability issues in the configuration script (b704571), correct the cross-host/cross-guest logic for --target=arch cross-compilation introduced in Proton-11 (68ab184), add support and documentation for building on macOS hosts (1a40f4d, 52eef9a), and add a useful build-step debugging targets (7f194d1).
Tested on 8GB M1 Mac Book, 16 GB M2 Mac mini, 32 GB M3 Mac mini, 36 GB M5 Mac Book Pro, 16 GB 2019 Intel Core-i9 (Intel Proton builds only) using macOS 15, and 26. Also tested on Linux Arch 2026-06-01 and Windows 11 26200.9168.
An independent PR which is useful but not necessary for builiding on Apple Silicon is #10086, which is better at automatically configuring the make -j parallelism based on the container's memory, rather than depending purely on the number of processors in the host. Both Windows and macOS constrained container defaults can make building Proton fail repeatedly due to OOM without this heuristic.