Package Details: wine32 11.0-1

Git Clone URL: https://aur.archlinux.org/wine32.git (read-only, click to copy)
Package Base: wine32
Description: A compatibility layer for running Windows programs on both 32-bit and 64-bit architectures (without WoW64)
Upstream URL: https://www.winehq.org
Licenses: LGPL-2.1-or-later
Conflicts: wine
Provides: wine
Submitter: 0xjmz
Maintainer: 0xjmz
Last Packager: 0xjmz
Votes: 18
Popularity: 1.42
First Submitted: 2025-06-29 07:30 (UTC)
Last Updated: 2026-01-14 08:59 (UTC)

Latest Comments

1 2 3 Next › Last »

Halano commented on 2025-12-14 15:54 (UTC)

Works 👍

0xjmz commented on 2025-11-12 10:28 (UTC)

I created a GitHub repository https://github.com/0xjmz/wine32 that includes a script for running the 32-bit version of Wine without relying on dependencies from the main Arch repository. There’s no need to compile anything; setup only takes a few minutes, depending on your internet connection speed.

0xjmz commented on 2025-11-11 10:21 (UTC)

Actually, I could try providing a wine32-bin package using a Podman container. It could even work alongside the Wine package from the repo. You could simply run it as the wine32 binary, and it would be independent of Arch dropping the lib32-* packages. Right now, I’m actually doing this for an old program that works better with older versions of Wine. Interestingly, WineHQ’s build system (dl.winehq.org) still compiles new 32-bit builds for distributions like Ubuntu 24.04 (can be used as container), so it’s definitely possible to maintain proper 32-bit support this way in the future.

0xjmz commented on 2025-11-10 17:41 (UTC) (edited on 2025-11-11 10:09 (UTC) by 0xjmz)

Well, as you can see from the package dependencies, it relies heavily on other packages. It’s likely that most of the required libraries will eventually be dropped from the main Arch repo and moved to the AUR. So even if I provided a binary for this package, you’d still need to compile most of the dependencies yourself.

That said, Wine 10.18 has improved WoW64 support for OpenGL quite a bit. There are still some programs that don’t run at all, but hopefully they’ll be fixed in upcoming releases.

ijann commented on 2025-11-10 03:36 (UTC) (edited on 2025-11-10 04:57 (UTC) by ijann)

Do you think you could create another package where it is wine32-bin and it is built please :( thanks

Riedler commented on 2025-10-26 11:43 (UTC)

thanks!

0xjmz commented on 2025-10-26 11:32 (UTC)

I don’t actually use clang myself, and honestly it seems unlikely many people will want to build this package with clang anyway. So yeah, let’s just force GCC explicitly for now and see how it goes — we can always revisit it later.

Riedler commented on 2025-10-26 11:01 (UTC)

but if the clang build is broken …? And I explicity requested not to have clang earlier.

If this package keeps trying to build with clang, I'd either have to switch back to gcc for every aur package, or switch back and forth every time I compile wine32.

Look, if you really want to keep a way to build wine32 with clang, please at least make the override a different variable. something like WINECC or FORCECC. That way people can still set it in /etc/makepkg.conf if they really want to, while letting others build a fully functioning package without having to change their system-wide default.

0xjmz commented on 2025-10-26 10:54 (UTC)

I don’t think it’s a good idea to hardcode GCC here, especially since you explicitly requested clang earlier. Hardcoding GCC/G++ could limit flexibility and make it harder for users who prefer or require clang-based builds.

Riedler commented on 2025-10-25 17:57 (UTC)

unfortunately, CC and CXX is exactly how a default compiler is meant to be set in /etc/makepkg.conf - is the override really necessary?

1 2 3 Next › Last »