algaos/algaos-ebuild-tree/eclass/wine.eclass, branch next

wine.eclass: Symlink fex-xtajit unixlib if present

2026-08-22T09:47:35Z

FEX's WoW64 xtajit implementation now includes a *nix lib. This is currently just a stub, however will be a hard requirement for using FEX with WINE in the near future. Rework the DLL symlinking to include the *nix libs as well as the DLLs. As a consequence, we now also depend on at least version 2608 of app-emulation/fex-xtajit. Signed-off-by: James Calligeros Part-of: https://github.com/gentoo/gentoo/pull/46667 Closes: https://github.com/gentoo/gentoo/pull/46667 Signed-off-by: Ionen Wolkens

wine.eclass: adapt postinst for wine-proton

2026-06-01T11:33:32Z

Went overlooked given wine-proton wasn't using postinst properly, but now it is. Fixes: 3ce7350b553c80439214ad1808ffc7bf48acc17d Closes: https://bugs.gentoo.org/976456 Signed-off-by: Ionen Wolkens

wine.eclass: cleanup readonly usage

2026-04-27T15:38:53Z

While this shouldn't be modified, there's also no real need to protect it. Removing feels more consistent with what classes do in general (aka not have readonly everywhere). Signed-off-by: Ionen Wolkens

wine.eclass: cleanup obsolete wine-proton workaround

2026-04-22T04:24:44Z

Signed-off-by: Ionen Wolkens

wine.eclass: update +wow64 wine-proton exception

2026-04-17T01:33:43Z

wine-proton-11.0.1_beta1 now exists and is based on wine-11, but wine-proton-9999 (bleeding-edge branch) is still based on wine-10.0 at the moment, odds are it will be rebased later but for now adjust this to pick 11 up. Hard to say how well this will work out consider I do not believe(?) upstream Proton is using/testing the new wow64 mode and it could potentially lead to build failures or other issues in the future. Willing to take the risks given most users do not want to deal with multilib if they can avoid it, esp. out of the box (fine to opt-in). Signed-off-by: Ionen Wolkens

wine.eclass: add C++ support

2026-03-11T11:55:04Z

Not looked at what it is needed for, but upstream wine has added support for using C++ in upcoming >=11.5 (incl. for cross) so add support here too. C++ was already used for dxvk so mingw64-toolchain should function properly for this. Hopefully not overlooked anything, but quite possible did. The changed logic still seems to work for C at least. Signed-off-by: Ionen Wolkens

wine.eclass: disable stack-protector globally

2026-03-08T08:05:53Z

Rather than just when doing cross (which was very broken), albeit ideal would be to figure out why this is happening. With mingw the implementation for security flags are often partial/dodgy, but the native bits should be different which implies most likely a bug in Wine (not planning to pursue this myself). Will not bother with revbumps given have not heard of other users having issues and pretty sure a few are using the flag esp. on hardened, there may be some conditions to hit the issue. wrt the -fno-stack*, generally should not be needed unless users setup their own mingw compiler using crossdev and had it use it by default (CFLAGS are mostly ignored, so almost nothing is passed). Closes: https://bugs.gentoo.org/970983 Signed-off-by: Ionen Wolkens

wine.eclass: enable USE=wow64 by default in >=wine-11

2026-01-26T01:12:17Z

No longer considered experimental, and default USE=abi_x86_32 has historically provided a terrible UX for Gentoo users (either have to figure out each packages that need it, or wastefully enable it globally). This should work fine for *most* people, but there are exceptions so also give a warning so users know what happened and how to revert. One (new) UX annoyance will be for existing users that were setting USE=abi_x86_32 either globally (rather than wine's specific set of dependencies) or on wine themselves will hit a conflict due to: REQUIRED_USE="wow64? ( !abi_x86_32 )" Aka means need to either disable USE=wow64 or USE=abi_x86_32, the latter to match defaults. A workaround would be to change abi_x86_32 into a no-op w/ wow64 but it would also be confusing for users in a different way and make the eclass messier. Another option would be a news item, but not convinced that it is worth it ("most" users will hopefully understand when portage prints the REQUIRED_USE constraints, and check the USE description). Users that were explcitly disabling wow64 may find themselves with a wine that has no 32bit support, but we do have an eclass warning about lack of 32bit as-is. Signed-off-by: Ionen Wolkens

wine.eclass: update llvm-mingw comment

2026-01-26T01:12:17Z

It is packaged, albeit only keyworded for ~arm64 at the moment and there seem to be little reason to actually use it here(?). Not that I plan to explore this myself. Signed-off-by: Ionen Wolkens

wine.eclass: Add arm64ec emulation support

2025-09-17T22:21:02Z

Enable building arm64ec dlls and hook up fex-emu Signed-off-by: Sasha Finkelstein Part-of: https://github.com/gentoo/gentoo/pull/43593 Closes: https://github.com/gentoo/gentoo/pull/43593 Signed-off-by: Sam James