| Summary: | app-emulation/wine-vanilla and wine-staging: add option for PE builds (--with-mingw) | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Simon <sur3> |
| Component: | Current packages | Assignee: | Wine Maintainers <wine> |
| Status: | RESOLVED FIXED | ||
| Severity: | major | CC: | alecm, bob.mt.wya, carlphilippreh, chris, forenhampel, sam, thomas |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
|
Description
Simon
2020-08-10 20:52:29 UTC
See also related arch bug: https://bugs.archlinux.org/task/67326 There are several problems to making this streamlined in gentoo, but you can still build it using mingw by passing EXTRA_ECONF="--with-mingw" and having mingw available (typically through crossdev), that's what I do. I do wish I could at least be spared from having to use EXTRA_ECONF, maybe a USE=mingw could be made which point to the mingw wiki page warning users to setup mingw themselves? If you have a working mingw environment I have wine-staging ebuilds in the FireBurn overlay with mingw support - it gets Blizzard's games working again (In reply to Simon from comment #0) > Updating from wine-staging-5.9 to 5.10 or higher breaks multiple games, > because wine-5.10+ needs to be compiled with mingw toolchain for native PE > libraries. > Please fix this and meanwhile add back wine-staging-5.9. > > Reproducible: Always I have the exact same problem and the more the wine and wine-staging versions go up, the more that stops working. I've got like 12 applications and games that stopped working after going in the upper wine releases (luckily I still have wine-staging-5.0 installed). If mingw resolves the issue, then why isn't this a USE flag? P.S.: While checking the ebuild I noticed multilib_src_configure() { local myconf=( --without-mingw # linux LDFLAGS leak in mingw32: bug #685172 ) Wouldn't it be possible to simply just include a mingw USE flag? It is referenced here: https://bugs.winehq.org/show_bug.cgi?id=45349#c14 and a bug that I created here: https://bugs.winehq.org/show_bug.cgi?id=49942 Yeah, we'll probably add a flag for it mingw, it's just that no one got to it yet. :] If you're in a rush at all, you might like to test the ebuilds from the overlay that has been mentioned. I'm sure they'll appreciate any testing and feedback there as well. I'll try to look into this sooner rather than later if no one else gets to it first. As for old versions, you can still find them via our Wine overlay (or/and Gentoo git history), but they aren't maintained too actively and may be broken from time to time. The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/proj/wine.git/commit/?id=0497bd02f32da6a89a4ee99a970c4b76147960e4 commit 0497bd02f32da6a89a4ee99a970c4b76147960e4 Author: Jimi Huotari <chiitoo@gentoo.org> AuthorDate: 2020-11-24 00:33:23 +0000 Commit: Jimi Huotari <chiitoo@gentoo.org> CommitDate: 2020-11-24 03:17:00 +0000 app-emulation/wine-staging: add USE="mingw" Using MinGW to build PE files has become more or less a requirement for some applications to still run via Wine, so let's not hard-disable it any longer. Bug: https://bugs.gentoo.org/736657 Package-Manager: Portage-3.0.10, Repoman-3.0.2 Signed-off-by: Jimi Huotari <chiitoo@gentoo.org> app-emulation/wine-staging/metadata.xml | 1 + .../wine-staging/wine-staging-5.22-r1.ebuild | 650 +++++++++++++++++++++ .../wine-staging/wine-staging-9999.ebuild | 33 +- 3 files changed, 682 insertions(+), 2 deletions(-) https://gitweb.gentoo.org/repo/proj/wine.git/commit/?id=f4db3c824ac162b28dfdb3d57645fc120a856624 commit f4db3c824ac162b28dfdb3d57645fc120a856624 Author: Jimi Huotari <chiitoo@gentoo.org> AuthorDate: 2020-11-17 00:18:59 +0000 Commit: Jimi Huotari <chiitoo@gentoo.org> CommitDate: 2020-11-24 03:16:43 +0000 app-emulation/wine-vanilla: add USE="mingw" Using MinGW to build PE files has become more or less a requirement for some applications to still run via Wine, so let's not hard-disable it any longer. Bug: https://bugs.gentoo.org/736657 Package-Manager: Portage-3.0.9, Repoman-3.0.2 Signed-off-by: Jimi Huotari <chiitoo@gentoo.org> app-emulation/wine-vanilla/metadata.xml | 1 + .../wine-vanilla/wine-vanilla-5.22-r1.ebuild | 568 +++++++++++++++++++++ .../wine-vanilla/wine-vanilla-9999.ebuild | 33 +- 3 files changed, 600 insertions(+), 2 deletions(-) ># TODO: Will bug 685172 still need special handling?
wine now use CROSSLDFLAGS and CROSSCFLAGS with mingw so I believe no leakage should happen anymore.
CROSSCFLAGS defaults to "-g -O2" if unset
CROSSLDFLAGS default to empty if unset
Does raise the question of if we want to set those in the ebuild, or just leave it up to users. I've been using CROSSCFLAGS="${CFLAGS}" in a wine-staging.conf for a while myself, but questionable as to how generally safe this is.
That aside, the new USE=mingw been working as expected and I removed my EXTRA_ECONF, thanks :)
Thanks for the info and feedback! I didn't include any check for the posix threads yet, which I've seen others do. I tested without, and so far did not notice any issues. Maybe they will eventually crop up? I did see it was mainly for building DXVK, and not for Wine itself, so perhaps that's to be expected. I'll close this one now since the changes landed in ::gentoo as well. |
