Hi all, I tried to update the wiki to document how to compile Wine on Apple Silicon, but I’m not sure if it went through. Basically, you need to add lld (which pulls in llvm) in addition to the other build dependencies So: brew install lld Then: PATH=`brew —prefix llvm`/bin:`brew —prefix bison`/bin:$PATH Then everything compiles. You probably don’t even need Xcode. And you probably should have Rosetta2 installed. I haven’t actually been able to get it to run yet, though… — Rob
Am Montag, 24. Februar 2025, 03:55:59 Ostafrikanische Zeit schrieb robert lippmann:
Hi all,
I tried to update the wiki to document how to compile Wine on Apple Silicon, but I’m not sure if it went through.
Basically, you need to add lld (which pulls in llvm) in addition to the other build dependencies
Generally if you want to run x86 Windows applications run both configure and make with arch -x86_64. Then it will all behave as if you were on an Intel CPU mac. You don't need to run the built wine with arch because it will be an x86_64 only binary. If you want to build things for arm to run arm64 Windows binaries you are in a world of trouble: * MacOS won't allow you to map anything below 4 GB, so Wine can't place the KSHARED_USER_DATA at 0x7ffe0000. * ARM MacOS has 16 kb pages whereas Windows has 4kb ones. We are working on both of those issues, but running an arm64 wine is going to take a while.
At minimum Xcode Command Line Tools are required. And as Stefan has pointed out your pretty much forced to build for x86_64 You can compile for x86_64 from an arm Terminal session but it’s simpler to build from an x86_64 Terminal session with ether an Intel brew install or MacPorts. Also something to keep in mind is a stock upstream wine compile won’t run nicely under Rosetta2. On Mon, Feb 24, 2025 at 3:39 AM Stefan Dösinger <stefandoesinger(a)gmail.com> wrote:
Am Montag, 24. Februar 2025, 03:55:59 Ostafrikanische Zeit schrieb robert lippmann:
Hi all,
I tried to update the wiki to document how to compile Wine on Apple Silicon, but I’m not sure if it went through.
Basically, you need to add lld (which pulls in llvm) in addition to the other build dependencies
Generally if you want to run x86 Windows applications run both configure and make with arch -x86_64. Then it will all behave as if you were on an Intel CPU mac. You don't need to run the built wine with arch because it will be an x86_64 only binary.
If you want to build things for arm to run arm64 Windows binaries you are in a world of trouble:
* MacOS won't allow you to map anything below 4 GB, so Wine can't place the KSHARED_USER_DATA at 0x7ffe0000.
* ARM MacOS has 16 kb pages whereas Windows has 4kb ones.
We are working on both of those issues, but running an arm64 wine is going to take a while.
On 24. Feb 2025, at 11:55, Dean Greer <gcenx83(a)gmail.com> wrote:
At minimum Xcode Command Line Tools are required.
And as Stefan has pointed out your pretty much forced to build for x86_64
You can compile for x86_64 from an arm Terminal session but it’s simpler to build from an x86_64 Terminal session with ether an Intel brew install or MacPorts.
Also something to keep in mind is a stock upstream wine compile won’t run nicely under Rosetta2.
I believe stock upstream wine should run decently well under Rosetta 2 in most cases at the moment.
On Feb 24, 2025, at 5:55 AM, Dean Greer <gcenx83(a)gmail.com> wrote:
At minimum Xcode Command Line Tools are required.
If you’re installing llvm, it might not be necessary since you are pulling in a whole new compiler toolchain. But, it’s not like it’s hard to install Xcode and command line tools.
Also something to keep in mind is a stock upstream wine compile won’t run nicely under Rosetta2.
Rosetta2 should work as it is also limited to 4k page sizes. Microsoft Windows arm does something similar using “prism” for running x86 binaries. So, it couldn’t be much worse than running x86 on Windows arm :) In any case, for future reference, if anyone wants to know how to build for arm on apple silicon, the way I outlined would be how to do it.
* MacOS won't allow you to map anything below 4 GB, so Wine can't place the KSHARED_USER_DATA at 0x7ffe0000.
Actually, Windows doesn’t do that anymore on 64 bit systems: https://msrc.microsoft.com/blog/2022/04/randomizing-the-kuser_shared_data-st...
* ARM MacOS has 16 kb pages whereas Windows has 4kb ones.
Yeah, that seems to be the sticking point. Asahi has that problem too. I’ve been thinking about that, and was wondering if it might just be a better idea to delegate functions to their UIKit/Foundation/whatever frameworks. It would probably need to be a fork, since Wine can’t have objective C code (and Apple is moving to Swift anyway). Or, I saw this for making Cocoa C bindings: https://github.com/FelixK15/c_ocoa FelixK15/c_ocoa github.com
It’s not a great idea to use too many macOS only functions over FOSS Unix libraries when possible. Wine used to use way more macOS backends and those quickly became broken and took a lot of convincing to remove said dead code. On Mon, Mar 10, 2025 at 10:54 PM robert lippmann < robert.lippmann.development(a)gmail.com> wrote:
* MacOS won't allow you to map anything below 4 GB, so Wine can't place the
KSHARED_USER_DATA at 0x7ffe0000.
Actually, Windows doesn’t do that anymore on 64 bit systems:
msrc.microsoft.com <https://msrc.microsoft.com/blog/2022/04/randomizing-the-kuser_shared_data-structure-on-windows/>
<https://msrc.microsoft.com/blog/2022/04/randomizing-the-kuser_shared_data-structure-on-windows/> <https://msrc.microsoft.com/blog/2022/04/randomizing-the-kuser_shared_data-structure-on-windows/>
* ARM MacOS has 16 kb pages whereas Windows has 4kb ones.
Yeah, that seems to be the sticking point. Asahi has that problem too.
I’ve been thinking about that, and was wondering if it might just be a better idea to delegate functions to their UIKit/Foundation/whatever frameworks.
It would probably need to be a fork, since Wine can’t have objective C code (and Apple is moving to Swift anyway).
Or, I saw this for making Cocoa C bindings: [image: c_ocoa.png]
FelixK15/c_ocoa <https://github.com/FelixK15/c_ocoa> github.com <https://github.com/FelixK15/c_ocoa> <https://github.com/FelixK15/c_ocoa>
On Monday, March 10, 2025 9:54:18 PM Central Daylight Time robert lippmann wrote:
* MacOS won't allow you to map anything below 4 GB, so Wine can't place the KSHARED_USER_DATA at 0x7ffe0000.
Actually, Windows doesn’t do that anymore on 64 bit systems:
https://msrc.microsoft.com/blog/2022/04/randomizing-the-kuser_shared_data-st ructure-on-windows/
That's not quite what you think. Microsoft can't actually move the KUSD without breaking things in both the user and the kernel; it's de facto API. Rather, what they did is make the *kernel* page read-only (the user page was already read-only), and map a writable copy at a different address (the kernel page needs to be writable so that the kernel can update dynamic fields like time). This doesn't help us because we still need to map the read-only page.
I noticed Alexandre added a commit for 64k page sizes on ARM. Does that mean it’s one step closer? :)
participants (5)
-
Dean Greer -
Elizabeth Figura -
Marc-Aurel Zent -
robert lippmann -
Stefan Dösinger