Wine on arm64. Is it possible?

[fredolic]

Dear all,

I would like to install wine (wine-vanilla) on an arm64 system (Apple Silicon, M1). I have seen this post from 4 years ago, and have tried playing with the USE flags and the "abi_x86_32". But it is still complaining about

[Ionen]

The current ebuild is simply not setup for non-x86/amd64 at all, and relies on either or both of these USE being set. If yank the requirement, it would not even run ./configure because it'd think it has nothing to do among other issues. At the very least abi_x86_64 would need to be force-set or replaced, but that won't be the end of it.

May be simpler to just build it directly first than try to force the ebuild, the multiple ways to build it complicate things a lot in the current ebuild (mingw, no mingw, multilib, wow64 without multilib, 32-only, 64-only -- lot of this wouldn't be super relevant for a simple arm64-only build).

Not that I've actually tried wine on arm64 nor have hardware to, so can't really help (if I did maybe I'd look into updating the ebuild given I maintain it, but would still have little personal interest given the limited set of windows applications with arm64 builds and I imagine running these with wine will be even messier than amd64 given it's less tested).

[szatox]

Yeah, the first problem is that those windows binaries use different instructions set, so you'd have to start with qemu-user, which - being a full CPU emulation - is just slow.
This said, you _could_ try doing just that.
Build qemu with QEMU_USER_TARGETS="i386 x86_64" and maybe USE="static-user" (shouldn't be required in this case), and enable qemu-binfmt service to register qemu as the interpreter for foreign binaries.

After that... Well I'd try x86 wine first, though the whole thing is getting very messy very quickly and probably won't work either way.

[Ionen]

[fredolic]

Thank you all for the replies.

I see it seems a lot of trouble, with qemu also being involved.

Well, let me start from the beginning and maybe you have more ideas: my goal is to make Microsoft Word and Adobe Acrobat to work with ARM. No games or something very demanding. Adobe Acrobat because sometimes I have to digitally sign documents. Okular does the trick, mostly, so that is not a MUST. MS Word neither, as LibreOffice mostly does the trick as well. But every once in a while it would be great to have them available, if the trouble was minimal. But as you paint it, it seems too much trouble for something that I can live without.

What do you think?

[pingtoo]

Why not just use a VM? load with MS Windows that should guarantee you choice of applications work.

[fredolic]

Of course, VirtualBox is something that I use in an amd64 laptop. But in this case, with an apple silicon this is no more the option. Then, I've inquired and it seems that qemu should be the other candidate, but before trying something as a VM from scratch I was asking whether something that seemed easier (wine) would do the trick?

Any suggestion of VM for the situation? Is qemu the one?

[szatox]

Running a VM will be easier than fitting a square peg into a round hole with wine.
Qemu does offer full cpu emulation mode, so yeah, give it a try. Add virt-manager for a convenient interface. And I suggest USE="spice", since it's more convenient than VNC or SDL displays.

[flysideways]

You can run Arm virtual machines on Apple Silicon with VMWare Fusion or UTM. UTM is supposed to also do emulation, but I have not tried it. Both have free versions.

[fredolic]

OK, thank you then. Qemu it is (it is really the push that I was needing to). Plus virt-manager.

UTM seems qemu based, so I'll go for the qemu anyway. And VMWare Fusion is not free, so for now I think I can manage.

Thank you all.

[flysideways]

[ian.au]

fredolic,

If the only use case for this Windows VM is as stated above, ie. editing .pdf's and interacting with word / ms-office documents generally, I've been able to do that in gentoo for years without a windows install.

In 2013 it was still sometimes painful to do this, but in 2023 it really isn't. If you build libreoffice with the pdfimport flag you can edit quite complex pdf's (in Draw, NOT Writer)

Usually I just use it to fill forms and stamp in a sig for pdf's. With word docs, you can either use google docs or libreoffice writer - the three are just about interchangeable until you get to really complex formatted stuff, again, can't remember the last time I had to really suffer with this in recent times.

Qemu is great, but setting it up for this isn't necessary. Building libreoffice on a low end ARM device is another issue though I'm not sure if the binary has pdfimport activated.

Cheers,

[wanne32]

Adobe Acrobat is not available for arm64. They recommend you to use VMs on windows anyway. So putting it into qemu seems the right way. – Or just use alternatives. Chromes pdf tool is horribly slow but quite powerful. LO was already mentioned.

[HuskyDog]