Apple Silicon compilation

[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
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

[Stefan Dösinger]

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.

[Dean Greer]

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 
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.

[Marc-Aurel Zent]

> On 24. Feb 2025, at 11:55, Dean Greer  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.

[robert lippmann]

> On Feb 24, 2025, at 5:55 AM, Dean Greer  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.

[robert lippmann]

> - 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%EF%BF%BC
FelixK15/c_ocoa
github.com

[Dean Greer]

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 <
[e-mail]> 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

[Elizabeth Figura]

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.