Package Details: proton-ge-custom 1:6.20.GE.1-1

Git Clone URL: (read-only, click to copy)
Package Base: proton-ge-custom
Description: Compatibility tool for Steam Play based on Wine and additional components, GloriousEggroll's custom build
Upstream URL:
Keywords: dxvk proton steam valve vkd3d wine
Licenses: custom
Provides: proton
Submitter: loathingkernel
Maintainer: loathingkernel
Last Packager: loathingkernel
Votes: 14
Popularity: 1.84
First Submitted: 2020-03-23 23:52
Last Updated: 2021-10-25 18:40

Dependencies (189)

Required by (1)

Sources (32)

Pinned Comments

loathingkernel commented on 2020-11-21 10:28

Notes about this package

  • If you encounter issues while using this package, please contact me here first before reporting an issue to the upstream repository. Don't post logs, link to them. If you are using Manjaro, another derivative or an AUR helper, please mention it, I DO NOT TEST AGAINST THEM AND I CANNOT KNOW WHAT MIGHT BE WRONG WITH THE DISTRO/HELPER OF YOUR CHOICE.

  • It takes a LOT of time and space to build. Building with multiple jobs helps but might cause builds to fail in rare cases. Be sure to have at least 16GB of RAM if you are building on tmpfs

  • It is NOT built against steam linux runtime and as such it doesn't require it.

  • This PKGBUILD uses CFLAGS, CXXFLAGS and LDFLAGS hardcoded in the PKGBUILD itself. By default it uses the same C[XX]FLAGS as upstream, namely -march=nocona and -mtune=core-avx2. To change them you will have to edit the PKGBUILD itself. Due to the nature of this package some flags can cause it to fail to build or not function properly. I try to filter them out but it is based on testing. If you have a feeling that compile-time options are involved in the issues you are having please include them in your comment. Currently the filtered options are -fstack-protector-{,-strong,-all}(dxvk and vkd3d only), -fno-plt, -z,relro, -z,now. Also the use of AVX instructions is disabled through -mno-avx.

  • If you are not using CFLAGS and CXXFLAGS specific to your system this package won't offer much in terms of performance as the upstream build flags already target the nocona (Core2) architecture. It will possibly perform worse than upstream. The only benefits you get is not depending on steam linux runtime as well as linking to Arch libraries. If you still want to build it, you can uncomment the relevant lines in the PKGBUILD to enable CFLAGS and CXXFLAGS similar to the upstream.

  • There have been reports with afdko failing to find its dependencies during building. I can't do anything about that as I don't maintain that package. It is NOT an issue with this package and I haven't found a way to not depend on it. Please don't report fails due to afdko (or any of its python- dependencies, they are pulled in due to afdko and only used by that), it has been discussed enough. There are possible workarounds in the comments.

  • It contains a patch to store game prefixes in the main Steam Library under $HOME/.local/share/Steam/steamapps/compatdata. It helps with isolation of game prefixes between users and works around issues with shared libraries on NTFS partitions due to drive symlinks. To enable it, set the PROTON_USER_COMPAT_DATA env variable to 1.

Latest Comments

1 2 3 4 5 6 ... Next › Last »

ptr1337 commented on 2021-10-19 09:20

Prebuilt packages can be found here:

how to add this repo:

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

loathingkernel commented on 2021-10-16 22:56

@adamant.pwn I could not replicate the failure in a clean fully updated Arch chroot. Odds are that it is something specific to your system.

adamant.pwn commented on 2021-10-16 20:59

I tried compiling it with both yay and makepkg, both resulted in this

FAILED: ext/wayland/ 
gcc -m32  -o ext/wayland/ ext/wayland/ ext/wayland/ ext/wayland/ ext/wayland/ ext/wayland/ ext/wayland/ ext/wayland/ ext/wayland/ ext/wayland/ ext/wayland/ ext/wayland/ -L/home/adamant/AUR/proton-ge-custom/src/build/dst-gst_orc32/lib -L/home/adamant/AUR/proton-ge-custom/src/build/dst-gstreamer32/lib -L/home/adamant/AUR/proton-ge-custom/src/build/dst-gst_base32/lib -I/home/adamant/AUR/proton-ge-custom/src/build/dst-gst_orc32/include -I/home/adamant/AUR/proton-ge-custom/src/build/dst-gstreamer32/include -I/home/adamant/AUR/proton-ge-custom/src/build/dst-gst_base32/include -flto -Wl,--as-needed -Wl,--no-undefined -Wl,-O1 -shared -fPIC -Wl,--start-group -Wl,-soname, -Wl,-Bsymbolic-functions -Wl,-rpath-link=/home/adamant/AUR/proton-ge-custom/src/build/dst-gst_orc32/lib -Wl,-rpath-link=/home/adamant/AUR/proton-ge-custom/src/build/dst-gstreamer32/lib -Wl,-rpath-link=/home/adamant/AUR/proton-ge-custom/src/build/dst-gst_base32/lib -Wl,-O1,--sort-common,--as-needed -gdwarf-2 -gstrict-dwarf -O3 -march=nocona -mtune=core-avx2 -pipe -mno-avx -mno-avx2 -mfpmath=sse -fwrapv -fno-strict-aliasing -ffile-prefix-map=/home/adamant/AUR/proton-ge-custom/src/build/src-gst_bad=. -mstackrealign -gdwarf-2 -gstrict-dwarf -O3 -march=nocona -mtune=core-avx2 -mno-avx -mno-avx2 -mfpmath=sse -fwrapv -fno-strict-aliasing -ffile-prefix-map=/home/adamant/AUR/proton-ge-custom/src/build/src-gst_bad=. -mstackrealign '-Wl,-rpath,$ORIGIN/../../gst-libs/gst/wayland' -Wl,-rpath-link,/home/adamant/AUR/proton-ge-custom/src/build/obj-gst_bad32/gst-libs/gst/wayland gst-libs/gst/wayland/ /home/adamant/AUR/proton-ge-custom/src/build/dst-gstreamer32/lib/ /usr/lib32/ /usr/lib32/ /home/adamant/AUR/proton-ge-custom/src/build/dst-gst_base32/lib/ /home/adamant/AUR/proton-ge-custom/src/build/dst-gstreamer32/lib/ /home/adamant/AUR/proton-ge-custom/src/build/dst-gst_base32/lib/ /usr/lib32/ /usr/lib32/ -Wl,--end-group
/usr/bin/ld: /tmp/ccpwxh7U.ltrans0.ltrans.o: in function `gst_wayland_sink_begin_geometry_change':
/usr/include/wayland-client-protocol.h:5881: undefined reference to `wl_proxy_marshal_flags'
/usr/bin/ld: /tmp/ccpwxh7U.ltrans0.ltrans.o: in function `gst_wayland_sink_end_geometry_change':
/usr/include/wayland-client-protocol.h:5911: undefined reference to `wl_proxy_marshal_flags'
/usr/bin/ld: /tmp/ccpwxh7U.ltrans0.ltrans.o: in function `gst_wl_buffer_finalize':
/usr/include/wayland-client-protocol.h:1998: undefined reference to `wl_proxy_marshal_flags'
/usr/bin/ld: /tmp/ccpwxh7U.ltrans0.ltrans.o: in function `gst_wl_buffer_force_release_and_unref':
/usr/include/wayland-client-protocol.h:1998: undefined reference to `wl_proxy_marshal_flags'
/usr/bin/ld: /tmp/ccpwxh7U.ltrans0.ltrans.o: in function `handle_xdg_wm_base_ping':
/home/adamant/AUR/proton-ge-custom/src/build/obj-gst_bad32/ext/wayland/xdg-shell-client-protocol.h:541: undefined reference to `wl_proxy_marshal_flags'
/usr/bin/ld: /tmp/ccpwxh7U.ltrans0.ltrans.o:/usr/include/wayland-client-protocol.h:3274: more undefined references to `wl_proxy_marshal_flags' follow
collect2: error: ld returned 1 exit status

loathingkernel commented on 2021-09-28 17:15

@C0D3-M4513R I have had this happen to other people too but not me. afdko is supposed to be installed through pip as the AUR package used to break regularly. Can you give me some information about your setup or a log to see why this is happening?

Edit: let me guess, you are using yay. yay has the bad habit of not retaining the environment between prepare() and build(). It works with makepkg as intended.

C0D3-M4513R commented on 2021-09-28 16:59

afdko was not a dependency of this package. I had to manually install, since it isn't installed by default.

thaewrapt commented on 2021-09-07 12:21

@loathingkernel My build platform is Core2 without any AVX support, maybe that's the source of the problem.

loathingkernel commented on 2021-09-07 11:51

@thaewrapt I am against that idea for two reasons. The default flags specified in makepkg.conf (-march=x86_64) will cause unknowing users to use lesser optimizations than upstream. At this moment these flags are what upstream uses too. If a user decides to edit them or even notices the discrepancy, I would prefer them to take a look at the PKGBUILD before adjusting them, because the reasoning and potential issues are documented there too, for the same reasons that are mentioned in the pinned comment.

That being said it is not clear to me what you are proposing. What should be checked before setting -march?

thaewrapt commented on 2021-09-07 11:42

PS I've read the pinned comment, can we at least add the check if the pre-requisites for -march change are met prior to setting it? I would try to think if there is a better way to work this around, but I cannot think of any right now.

loathingkernel commented on 2021-09-07 11:41

@thaewrapt There are good reasons for doing that, as explained in the pinned comment. Please read them. if you want clarifications to the reasoning I am happy to provide them. What platforms does this cause issues with?

thaewrapt commented on 2021-09-07 11:34

Please do not override -march (and probably CFLAGS at all) in PKGBUILD, as it breaks build process on some platforms, rendering this package unusable. If someone would want anything except "generic", it's achievable via /etc/makepkg.conf settings.