Package Details: wine-ge-custom 1:GE.Proton7.20-1

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, wine-wow64
Provides: wine, wine-wow64
Submitter: loathingkernel
Maintainer: loathingkernel
Last Packager: loathingkernel
Votes: 20
Popularity: 3.99
First Submitted: 2021-09-01 22:06 (UTC)
Last Updated: 2022-06-30 14:43 (UTC)

Required by (307)

Sources (6)

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.

Latest Comments

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: https://github.com/Frogging-Family/wine-tkg-git/issues/764

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: https://aur.archlinux.org/cgit/aur.git/commit/?h=wine-ge-custom&id=68775216a1641b99e7e86d6f01a132670f481a3a

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

loathingkernel commented on 2022-05-08 17:54 (UTC)

@ten98, build it with one makejob, I am aware of the issue but there isn't a fix nor even the cause of it is known to me yet.

ten98 commented on 2022-05-08 17:11 (UTC) (edited on 2022-05-08 18:55 (UTC) by ten98)

I am having a similar issue as @proledatarian with aur/wine-ge-custom 1:GE.Proton7.10-1 -> 1:GE.Proton7.11-1. My build is failing at:

/usr/bin/x86_64-w64-mingw32-dlltool: dlls/winmm/libwinmm.delay.a: error reading winmm_dll_s00184.o: file truncated
tools/winebuild/winebuild -b x86_64-w64-mingw32 -w --implib -o dlls/cryptnet/libcryptnet.delay.a --export \
  ../wine-ge-custom/proton-wine/dlls/cryptnet/cryptnet.spec
winebuild: /usr/bin/x86_64-w64-mingw32-dlltool failed with status 1
make: *** [Makefile:308324: dlls/winmm/libwinmm.delay.a] Error 1
make: *** Waiting for unfinished jobs....
/usr/bin/x86_64-w64-mingw32-dlltool: reopening winmm_dll_t.o: No such file or directory
/usr/bin/x86_64-w64-mingw32-dlltool: dlls/winmm/libwinmm.cross.a: error reading winmm_dll_t.o: No such file or directory
winebuild: /usr/bin/x86_64-w64-mingw32-dlltool failed with status 1
make: *** [Makefile:308324: dlls/winmm/libwinmm.cross.a] Error 1
../wine-ge-custom/proton-wine/dlls/win32u/font.c: In function ‘font_GetTextExtentExPoint’:
../wine-ge-custom/proton-wine/dlls/win32u/font.c:4072:41: warning: ‘abc.abcC’ may be used uninitialized in this function [-Wmaybe-uninitialized]
 4072 |         pos += abc.abcA + abc.abcB + abc.abcC; 
      |                                      ~~~^~~~~
../wine-ge-custom/proton-wine/dlls/win32u/font.c:4058:9: warning: ‘abc.abcB’ may be used uninitialized in this function [-Wmaybe-uninitialized]
 4058 |     ABC abc;
      |         ^~~
../wine-ge-custom/proton-wine/dlls/win32u/font.c:4072:19: warning: ‘abc.abcA’ may be used uninitialized in this function [-Wmaybe-uninitialized]
 4072 |         pos += abc.abcA + abc.abcB + abc.abcC;
      |                ~~~^~~~~
==> ERROR: A failure occurred in build().
    Aborting...
 -> error making: wine-ge-custom

I'm using the 2.38-2 build of mingw-w64-binutils from the official repo.

As per @loathingkernel resolved by editing makepkg.conf and temporarily setting MAKEFLAGS="-j1"

proledatarian commented on 2022-04-27 10:41 (UTC)

@loathingkernel Yeah, it was an issue with mingw-binutils from the community-testing repo.

loathingkernel commented on 2022-04-26 19:41 (UTC)

@proledatarian I rerun the build in my CI and it built correctly. This might be on your end.

proledatarian commented on 2022-04-26 15:48 (UTC) (edited on 2022-04-26 15:50 (UTC) by proledatarian)

I get the following error when updating using yay:

tools/winebuild/winebuild -b x86_64-w64-mingw32 -w --implib -o dlls/rpcrt4/librpcrt4.delay.a --export \
../wine-ge-custom/proton-wine/dlls/rpcrt4/rpcrt4.spec
/usr/bin/x86_64-w64-mingw32-dlltool: dlls/rpcrt4/librpcrt4.cross.a: error reading rpcrt4_dll_h.o: file truncated
/usr/bin/x86_64-w64-mingw32-dlltool: failed to open temporary head file: rpcrt4_dll_h.o: No such file or directory
winebuild: /usr/bin/x86_64-w64-mingw32-dlltool failed with status 1
make: [Makefile:242784: dlls/rpcrt4/librpcrt4.delay.a] Error 1
winebuild: /usr/bin/x86_64-w64-mingw32-dlltool failed with status 1
make:
Waiting for unfinished jobs....
make: *** [Makefile:242784: dlls/rpcrt4/librpcrt4.cross.a] Error 1
==> ERROR: A failure occurred in build().
Aborting...
-> error making: wine-ge-custom

loathingkernel commented on 2022-04-14 15:35 (UTC)

@sakure You are supposed to have the base-devel group installed if you want to build packages from the AUR and pkgconf is part of that group. The dependencies that are part of that group should NOT be included in the depends and makedepends arrays.

https://wiki.archlinux.org/title/Arch_User_Repository#Getting_started

https://wiki.archlinux.org/title/PKGBUILD#makedepends

sakure commented on 2022-04-14 14:22 (UTC) (edited on 2022-04-14 14:23 (UTC) by sakure)

this requires the 'pkgconf' as a make package by default, wine uses pkgconf to detect some libraries like freetype, it will fail with

configure: error: FreeType 64-bit development files not found. Fonts will not be built. Use the --without-freetype option if you really want this.

otherwise.

ufo_driver commented on 2022-04-05 21:02 (UTC)

@loathingkernel interesting, I tried to tag too but it did not work for me. Maybe I had wrong tag string or annotation message. Anyways your method works, thank you.

loathingkernel commented on 2022-04-05 16:41 (UTC)

@Ghul Read the pinned comment please. No they are not built on Arch, they are built on the lutris runtime. Still, not the scope of this package.

Ghul commented on 2022-04-05 16:15 (UTC) (edited on 2022-04-05 16:16 (UTC) by Ghul)

why not directly provide the prebuild wine-ge releases ? They are already built on archlinux.

loathingkernel commented on 2022-04-04 12:30 (UTC)

@ufo_driver Thanks for this, it can also be fixed by tagging the checked out commit as 7.0, but I am unsure if I should do either in the first place.

ufo_driver commented on 2022-04-04 11:51 (UTC) (edited on 2022-04-04 11:53 (UTC) by ufo_driver)

To fix versioning reporting you can add following line in your PKGBUILD inside prepare block right after patch -p1 ... lines

sed -i "s/GIT_DIR=\${wine_srcdir}.git git describe HEAD 2>\\/dev\\/null || echo \\\\\"wine-\\\\\$(PACKAGE_VERSION)\\\\\"/echo \\\\\"wine-7.0\\\\\"/g" configure.ac

Idea stolen from wine-tkg-git build script.

endlesik commented on 2022-03-12 16:53 (UTC)

@loathingkernel I see! The more you know :) You're right, thanks for clarifying!

loathingkernel commented on 2022-03-11 17:54 (UTC) (edited on 2022-03-11 17:56 (UTC) by loathingkernel)

@endlesik It is not the package but the sources, wine-ge-custom has been rebased on Valve's wine fork instead of upstream wine, and the later tags do not exist in their repository.

To be exact the version is wine-5.12-13989-gca3681631ad, which means that it is 13989 commits after version 5.12, which aligns with the version 7.0 reported by winecfg and wineserver -v. Why tools like lutris are being silly and base their version checking on wine and not wineserver is beyond me. The version in wine is derived by the build-system from the repository information at build-time, where wineserver version is set by the developers.

endlesik commented on 2022-03-11 17:20 (UTC)

Hi, some time ago (I think max two weeks period from now) something broke - whenever I'm installing wine-ge-custom using AUR helper (paru), it installs correctly, but wine --version returns wine-5.12-13989-gca3681631ad.. - it was returning 7.x for sure not that long ago.

Lutris also detects 5.12 as systems' Wine (was detecting 7.x and still is, if I install wine-staging)

Maybe I screwed something with my config, but thus far was unable to find the culprit (removing default .wine prefix didn't change anything)

Tried to install AUR manually, the effect is the same.. maybe it's the package itself

SleepingPanda commented on 2022-03-08 01:18 (UTC) (edited on 2022-03-08 01:54 (UTC) by SleepingPanda)

@loathingkernel Alright. I'll try again. Thanks for the hints. Edit: It worked. Thanks for the help!

loathingkernel commented on 2022-03-08 01:02 (UTC) (edited on 2022-03-08 01:05 (UTC) by loathingkernel)

@SleepingPanda that is an internal compiler error (what that might entail I am not sure without knowing more about how you are trying to compile it), that is hardly something I can help you with. Try again in a clean chroot or with one compiler job and see if it happens there too.

SleepingPanda commented on 2022-03-08 00:44 (UTC) (edited on 2022-03-08 00:44 (UTC) by SleepingPanda)

Hey there. I'm unable to make this new version of wine-ge-custom 1:GE.Proton7.5-1. This is the error I get while building it:

    ../wine-ge-custom/proton-wine/dlls/dsound/eax.c:1095:1: internal compiler error: Segmentation fault
     1095 | }
          | ^
    0x15bfcc8 internal_error(char const*, ...)
        ???:0

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

Strykar commented on 2022-03-02 14:02 (UTC)

@loathingkernel Any chance you would please ship a wine-ge-custom-bin package too?

loathingkernel commented on 2022-02-16 15:11 (UTC)

@SleepingPanda It is fixed now, forgot to edit the reply.

SleepingPanda commented on 2022-02-16 15:08 (UTC)

@loathingkernel Thanks for the swift response! I'll continue using the older version until then. Also thank you so much for maintaining this package.

loathingkernel commented on 2022-02-15 13:14 (UTC) (edited on 2022-02-15 14:11 (UTC) by loathingkernel)

@SleepingPanda I assume it is the new glibc and linux-api-headers, gonna have to take a look deeper.

SleepingPanda commented on 2022-02-15 03:07 (UTC) (edited on 2022-02-15 11:58 (UTC) by SleepingPanda)

I'm having trouble building this version (7.2.GE.2-1). Is anyone else encountering issues with futexes?

loathingkernel commented on 2022-01-23 03:07 (UTC)

@Nu4425 No, there won't be any problems, I just overlooked adding those comments. You have to be careful with the specified flags, some might cause issues but if it is just adding -march=native, you won't face any issues.

Nu4425 commented on 2022-01-23 01:49 (UTC) (edited on 2022-01-23 01:52 (UTC) by Nu4425)

@loathingkernel, I noticed unlike the other packages you maintain that documentation in this PKGBUILD is absent about compiling natively by passing -march=native and omitting -mtune=core-avx2 for the CFLAGS and CXXFLAGS variables.

If one wishes to compile natively this way, will there be any problems in the built package's functionality? If there will be, what are your recommendations?

loathingkernel commented on 2022-01-22 11:54 (UTC) (edited on 2022-01-22 11:56 (UTC) by loathingkernel)

@Neko-san the specific compiler that is required is the default compiler and not something that can or will change without user intervention. I am against polluting the script with safeguards against user-defined options, it is a bottomless pit as there is no way to safeguard against everything. The reason certain flags are enforced is because Arch defaults will cause the build process to fail, and the next best candidates are the Proton flags.

Neko-san commented on 2022-01-18 18:10 (UTC) (edited on 2022-01-18 18:20 (UTC) by Neko-san)

@loathingkernel On the contrary, I disagree considering that, if a maintainer knows a specific compiler is required, then they should enforce that the necessary compiler is used.

That aside, I do compile in chroots, and user compiler preference has no bearing on that.

loathingkernel commented on 2022-01-18 09:34 (UTC) (edited on 2022-01-18 09:35 (UTC) by loathingkernel)

@Neko-san That is the user's responsibility, not the PKGBUILD's. PKGBUILDs from AUR should be built in clean chroots anyways.

Neko-san commented on 2022-01-18 00:42 (UTC)

Might want to add:

    if [ "$CC" = 'clang' ] && [ "$CXX" = 'clang++' ] || [ "$CC" = 'clang' ] || [ "$CXX" = 'clang++' ] ; then
        export CC=gcc
        export CXX=g++
        export LD=ld
        export AR=""
        export NM=""
        export RANLIB=""
        export STRIP=""
        export OBJCOPY=""
        # Reset debug flags to makepkg.conf defaults, in case Clang is globally set
        export DEBUG_CFLAGS="-g -fvar-tracking-assignments"
        export DEBUG_CXXFLAGS="-g -fvar-tracking-assignments"
    fi

To make sure that, if a user has clang globally set, that it gets unset back to the Arch defaults to prevent builds from failing.

ptr1337 commented on 2021-10-19 09:31 (UTC)

Prebuilt packages can be found here: https://mirror.cachyos.org/?search=wine

how to add this repo:

https://wiki.cachyos.org/en/home/Repo

The packages are built with x86-64 and the optimized x86-64-v3 if your cpu supports that.

loathingkernel commented on 2021-10-15 11:14 (UTC) (edited on 2021-10-15 11:15 (UTC) by loathingkernel)

@thaewrapt Yes, it is a replacement for regular wine, which can also be used in Lutris as it supports using the system-wide wine.

thaewrapt commented on 2021-10-15 10:56 (UTC) (edited on 2021-10-15 10:57 (UTC) by thaewrapt)

@loathingkernel Yeah, I see your point as well. With lutris only looking into ~/.local directory for its runners, a possible way is to have a system-wide installation (either in the form of tar archive or extracted) with a shell script that should be run by the enduser from their own gaming account to update local runners directory with a current version from system-wide distribution. Or, as an alternative, one could use a third party script which will just plain download the latest version (or the version of choice) from github releases and put it directly inside the same runners directory.

But, anyway, this is offtopic to this particular AUR package, I guess (as it just provides the alternative to a system-wide wine, correct?).

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.

thaewrapt commented on 2021-10-15 09:11 (UTC)

@loathingkernel I think he's talking about wine-ge-custom-bin package (or however it could be called), meaning automated installation of the prebuilt binaries from https://github.com/GloriousEggroll/wine-ge-custom/releases

loathingkernel commented on 2021-10-07 12:05 (UTC) (edited on 2021-10-07 12:05 (UTC) by loathingkernel)

@Tomoghno nope, there are repos packaging this PKGBUILD out there, you can use one of those. Also, PKGBUILDs packaging the binary results of other PKGBUILDs are STRICTLY prohibited in the AUR.

Tomoghno commented on 2021-10-07 11:56 (UTC)

Can You Make a Binary Package for it ...

loathingkernel commented on 2021-09-27 15:06 (UTC) (edited on 2021-09-27 16:12 (UTC) by loathingkernel)

@kenga I moved a few environment variables around and it should be ok with yay too now. That being said I still believe that the assumptions yay is making are wrong and they definitely are not the default behavior of makepkg. Just something to keep in mind if other issues arise with it.

kenga commented on 2021-09-27 14:48 (UTC)

Yep, building directly with makepkg seems to work. Quite annoying, as yay had been playing nice so far.

Well, time to retire yet another helper I suppose...

loathingkernel commented on 2021-09-26 23:13 (UTC) (edited on 2021-09-26 23:44 (UTC) by loathingkernel)

I don't know what shitty things yay is doing and why but it doesn't follow the assumed makepkg way and it doesn't retain the environment between prepare() and build() as evident by the existence of filtered flags in your log. My guess is that it first prepares the sources and then starts the build again with a new environment for some reason.

Package builds fine in a clean chroot with Arch's proper tooling.

loathingkernel commented on 2021-09-26 22:39 (UTC) (edited on 2021-09-26 22:52 (UTC) by loathingkernel)

@kenga what distro are you on and are you using a helper? Try without a helper and if it persists, report back.

kenga commented on 2021-09-26 22:02 (UTC)

Fails for me without without any modifications of the PKGBUILD as well (6.18.GE.1-1, PKGBUILD commit a7aae53a9ff4)

<command-line>: warning: "_FORTIFY_SOURCE" redefined
<command-line>: note: this is the location of the previous definition
/home/user/.cache/yay/wine-ge-custom/src/wine-ge-custom-64-build/tools/winebuild/winebuild -w --def -o dlls/kernel32/libkernel32.def \
  -m32 --export ../wine-ge-custom/wine/dlls/kernel32/kernel32.spec
/home/user/.cache/yay/wine-ge-custom/src/wine-ge-custom-64-build/tools/winegcc/winegcc -o dlls/capi2032/capi2032.dll.so \
  --wine-objdir . --winebuild \
  /home/user/.cache/yay/wine-ge-custom/src/wine-ge-custom-64-build/tools/winebuild/winebuild -m32 \
  -fno-PIC -Wl,-z,notext -fasynchronous-unwind-tables -shared \
  ../wine-ge-custom/wine/dlls/capi2032/capi2032.spec -mcygwin dlls/capi2032/cap20wxx.o \
  libs/port/libwine_port.a -ldl -Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now 
/usr/bin/ld: dlls/capi2032/cap20wxx.o: direct GOT relocation R_386_GOT32X against `__wine_dbg_header' without base register can not be used when making a shared object
collect2: error: ld returned 1 exit status
winegcc: /usr/bin/gcc failed
make: *** [Makefile:16025: dlls/capi2032/capi2032.dll.so] Error 2
==> ERROR: A failure occurred in build().
    Aborting...
error making: wine-ge-custom

loathingkernel commented on 2021-09-24 21:37 (UTC)

@idle_zealot, you are having trouble because you edited the PKGBUILD without reading the comments.

idle_zealot commented on 2021-09-24 19:28 (UTC) (edited on 2021-09-24 19:28 (UTC) by idle_zealot)

I'm also having trouble building this.

<command-line>: warning: "_FORTIFY_SOURCE" redefined
<command-line>: note: this is the location of the previous definition
rm -f libs/port/libwine_port.a && ar rc libs/port/libwine_port.a \
  libs/port/getopt.o libs/port/lstat.o libs/port/mkstemps.o libs/port/poll.o libs/port/pread.o \
  libs/port/pwrite.o libs/port/readlink.o libs/port/spawn.o libs/port/symlink.o && ranlib libs/port/libwine_port.a
/home/user/.cache/yay/wine-ge-custom/src/wine-ge-custom-64-build/tools/winegcc/winegcc -o dlls/avicap32/avicap32.dll.so \
  --wine-objdir . --winebuild \
  /home/user/.cache/yay/wine-ge-custom/src/wine-ge-custom-64-build/tools/winebuild/winebuild -m32 \
  -fno-PIC -Wl,-z,notext -fasynchronous-unwind-tables -shared \
  ../wine-ge-custom/wine/dlls/avicap32/avicap32.spec dlls/avicap32/avicap32_main.o \
  libs/port/libwine_port.a -ldl -Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now 
/usr/bin/ld: dlls/avicap32/avicap32_main.o: direct GOT relocation R_386_GOT32X against `__wine_dbg_header' without base register can not be used when making a shared object
collect2: error: ld returned 1 exit status
winegcc: /usr/bin/gcc failed
make: *** [Makefile:13451: dlls/avicap32/avicap32.dll.so] Error 2
==> ERROR: A failure occurred in build().
    Aborting...
error making: wine-ge-custom

loathingkernel commented on 2021-09-22 23:20 (UTC)

Can't reproduce it, what version of vkd3d are you using?

DoubleAgentDave commented on 2021-09-22 15:12 (UTC)

Having problems building this, seems there is a naming problem, any ideas?

../wine-ge-custom/wine/dlls/d3d12/d3d12_main.c:346:10: error: ‘const struct vkd3d_application_info’ has no member named ‘api_version’; did you mean ‘engine_version’? 346 | .api_version = VKD3D_API_VERSION_1_2, | ^~~~~~~~~~~ | engine_version ../wine-ge-custom/wine/dlls/d3d12/d3d12_main.c:346:24: error: ‘VKD3D_API_VERSION_1_2’ undeclared (first use in this function); did you mean ‘VK_API_VERSION_1_2’? 346 | .api_version = VKD3D_API_VERSION_1_2, | ^~~~~~~~~~~~~~~~~~~~~ | VK_API_VERSION_1_2 ../wine-ge-custom/wine/dlls/d3d12/d3d12_main.c:346:24: note: each undeclared identifier is reported only once for each function it appears in make: *** [Makefile:29593: dlls/d3d12/d3d12_main.o] Error 1 ==> ERROR: A failure occurred in build(). Aborting...