| Git Clone URL: | https://aur.archlinux.org/wine-ge-custom.git (read-only, click to copy) |
|---|---|
| Package Base: | wine-ge-custom |
| Description: | A compatibility layer for running Windows programs - GloriousEggroll branch |
| Upstream URL: | https://github.com/GloriousEggroll/wine-ge-custom |
| Licenses: | LGPL |
| Conflicts: | wine |
| Provides: | wine |
| Submitter: | loathingkernel |
| Maintainer: | loathingkernel |
| Last Packager: | loathingkernel |
| Votes: | 35 |
| Popularity: | 1.53 |
| First Submitted: | 2021-09-01 22:06 (UTC) |
| Last Updated: | 2023-12-02 12:26 (UTC) |
@bootlegbilly Refer here for the reasoning https://aur.archlinux.org/packages/proton-ge-custom
In short, feel free to try it, but I can neither filter nor test with any possible flags that might cause breakages. It is left as an exercise to the user.
How come the PKGBUILD overwites any custom CFLAGS? Is there a reason this can't be built with -march=native, -flto, or -O3?
In addition to loathingkernel's PKGBUILDs on GitHub & ptr1337's repo, the Chaotic-AUR repo also provides automated compiled binaries for this package: https://aur.chaotic.cx/
I just built mingw-w64-binutils with slightly changed official PKGBUILD and now building Wine with all $(nproc) CPUs :)
@dogunaut You are correct, this is an upstream mingw-w64-binutils issue. Personally I am 100% unequivocally against downgrading a package like that, especially forcing it through a dependency mandate to any unaware user. Users might want to do that themselves, but I can't endorse it in the PKGBUILD.
Issue seems to be caused by a bug in binutils. Unsure how bad of an idea it is, but downgrading my binutils to the previous version allows me to compile with max jobs again without any problems.
Bug & workaround found here: https://github.com/Frogging-Family/wine-tkg-git/issues/764
@GIgas002 see earlier comments, there seems to be an issue with the build when running multiple jobs in parallel, so the latest change to the PKGBUILD is working around that by disabling that for now: https://aur.archlinux.org/cgit/aur.git/commit/?h=wine-ge-custom&id=68775216a1641b99e7e86d6f01a132670f481a3a
Hopefully, it's just a temporary thing.
Is it buildable right now? The 1:GE.Proton7.10-1 and previous versions built on my machine on 20-30 minutes, but 1:GE.Proton7.11-1 was building for more than hour, and I had to stop it.
@ten98 it has happened to me with two jobs while testing
@loathingkernel thanks, that did the trick. For reference I was building on a 3970x with MAKEFLAGS="-j$(nproc)" so it was launching 64 makejobs.
There may be some value of -jX where (1 < X < 64) that would consistently build clean without having to restrict to -j1. In which case you could compare $(nproc) to X and if $(nproc) < X do nothing, else set MAKEFLAGS="-jX".
Pinned Comments
loathingkernel commented on 2022-03-02 14:12 (UTC)
@Strykar Nope, see https://aur.archlinux.org/packages/wine-ge-custom#comment-831304
You can grab compiled packages from https://github.com/loathingKernel/PKGBUILDs/releases/tag/packages
loathingkernel commented on 2021-10-15 10:01 (UTC) (edited on 2021-10-15 10:04 (UTC) by loathingkernel)
@thaewrapt, I see, you might be correct. The prebuilt package is not a good candidate for packaging for a couple of reasons. First of all, it is built using Lutris's runtime, and as such inherits the same issues as Proton, namely it is at its best when running inside that runtime. Also, although I might be wrong here, I haven't found any mention of Lutris being able to use a system-wide installation directory in the same way Steam can. For these reasons, I believe that packaging those binaries is pointless and they should be managed by Lutris itself.