Package Details: wine-ge-custom 1:GE.Proton8.25-1

Git Clone URL: (read-only, click to copy)
Package Base: wine-ge-custom
Description: A compatibility layer for running Windows programs - GloriousEggroll branch
Upstream URL:
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)

Pinned Comments

loathingkernel commented on 2022-03-02 14:12 (UTC)

@Strykar Nope, see

You can grab compiled packages from

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.

Latest Comments

« First ‹ Previous 1 2 3 4 5 6 7 8 9 10 11 Next › Last »

loathingkernel commented on 2022-10-13 01:09 (UTC)

@bootlegbilly Refer here for the reasoning

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.

bootlegbilly commented on 2022-10-12 13:47 (UTC)

How come the PKGBUILD overwites any custom CFLAGS? Is there a reason this can't be built with -march=native, -flto, or -O3?

subsurf commented on 2022-08-06 04:44 (UTC)

In addition to loathingkernel's PKGBUILDs on GitHub & ptr1337's repo, the Chaotic-AUR repo also provides automated compiled binaries for this package:

ufo_driver commented on 2022-05-21 20:55 (UTC)

I just built mingw-w64-binutils with slightly changed official PKGBUILD and now building Wine with all $(nproc) CPUs :)

loathingkernel commented on 2022-05-10 13:59 (UTC) (edited on 2022-05-10 14:00 (UTC) by loathingkernel)

@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.

dogunaut commented on 2022-05-10 13:54 (UTC)

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:

airbreather commented on 2022-05-09 10:52 (UTC)

@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:

Hopefully, it's just a temporary thing.

Gigas002 commented on 2022-05-09 05:58 (UTC)

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.

loathingkernel commented on 2022-05-08 20:20 (UTC) (edited on 2022-05-08 20:20 (UTC) by loathingkernel)

@ten98 it has happened to me with two jobs while testing

ten98 commented on 2022-05-08 19:28 (UTC) (edited on 2022-05-08 20:11 (UTC) by ten98)

@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".