Package Details: proton-ge-custom 2:GE.Proton9.22-1

Git Clone URL: https://aur.archlinux.org/proton-ge-custom.git (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: https://github.com/GloriousEggroll/proton-ge-custom
Keywords: dxvk proton steam valve vkd3d wine
Licenses: custom
Provides: proton
Submitter: loathingkernel
Maintainer: loathingkernel
Last Packager: loathingkernel
Votes: 40
Popularity: 2.19
First Submitted: 2020-03-23 23:52 (UTC)
Last Updated: 2024-12-30 14:02 (UTC)

Dependencies (117)

Required by (7)

Sources (12)

Pinned Comments

loathingkernel commented on 2023-10-12 10:43 (UTC) (edited on 2023-10-12 10:45 (UTC) by loathingkernel)

@rekman, thank you for looking into CUDA issues, at least it gives me an idea on how to fix it. That being said, my position remains to build it in a clean chroot, away from the locally installed packages. It is not feasible for me to carry patches for the build systems of various subprojects in the long run.

By enabling the 0003-AUR-Remove-kaldi-openfst-vosk-api-modules-because-of patch, you lose voice recognition which I assume is not that big of a loss as I haven't encountered a use for it, so I think it is an acceptable alternative.

patlefort commented on 2022-09-22 00:33 (UTC)

Compilation will fail if you happen to have jwasm installed, due to vulkan loader. Workaround: uninstall jwasm or add this line to prepape() in the PKGBUILD:

sed -i 's/VULKAN_LOADER_CMAKE_ARGS = -DUSE_MASM=OFF/VULKAN_LOADER_CMAKE_ARGS = -DUSE_MASM=OFF -DJWASM_FOUND=0/' "$srcdir/$pkgname/Makefile.in"

loathingkernel commented on 2020-11-21 10:28 (UTC) (edited on 2022-09-13 10:55 (UTC) by loathingkernel)

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 (Sniper, Soldier, etc) and as such it doesn't require it. Still, is detected by Steam and works properly (preferable through steam-native).

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

  • This package requires a Rust 32 bit target, please run rustup target install i686-unknown-linux-gnu BEFORE posting any issues if you're using rustup.

Latest Comments

« First ‹ Previous 1 .. 8 9 10 11 12 13 14 15 16 17 18 .. 34 Next › Last »

ms178 commented on 2022-11-07 09:19 (UTC)

The last proton-ge-custom release doesn't work for me with Battlefield 1 since EA forced its crappy new launcher app to users. With my own custom build of the 7.38 version, it would work at least sometimes albeit showing a blank gray screen. I also had no luck with proton-experimental which is supposed to carry a bug fix for this problem. Any ideas how to fix this?

loathingkernel commented on 2022-09-22 10:39 (UTC) (edited on 2022-09-22 10:40 (UTC) by loathingkernel)

@patlefort Packages are supposed to be built in clean chroots, I don't think I should add such conditionals to the package for anything that it outside of the dependencies.

That's not to say that this won't help someone who hits the same error or that finding a workaround is not appreciated. In that regard I will pin your comment for future reference.

patlefort commented on 2022-09-22 00:33 (UTC)

Compilation will fail if you happen to have jwasm installed, due to vulkan loader. Workaround: uninstall jwasm or add this line to prepape() in the PKGBUILD:

sed -i 's/VULKAN_LOADER_CMAKE_ARGS = -DUSE_MASM=OFF/VULKAN_LOADER_CMAKE_ARGS = -DUSE_MASM=OFF -DJWASM_FOUND=0/' "$srcdir/$pkgname/Makefile.in"

loathingkernel commented on 2022-09-01 15:01 (UTC)

@IncredibleLaser I had this error, and I thought it was fixed with this change

Also it built properly on my CI so I am unsure why you are getting this error.

IncredibleLaser commented on 2022-09-01 14:34 (UTC)

I also get an error now trying to build in a clean CHROOT:

Checking for function "fbGetDisplay" with dependency egl: NO 
Message: No OpenGL Window systems found or requested

src-gst_base/gst-libs/gst/gl/meson.build:1102:2: ERROR: Problem encountered: GStreamer OpenGL integration required via options, but needed dependencies not found.

A full log can be found at /build/proton-ge-custom/src/build/obj-gst_base64/meson-logs/meson-log.txt
make[2]: *** [../proton-ge-custom/Makefile.in:560: /build/proton-ge-custom/src/build/.gst_base-configure64] Error 1
make[2]: Leaving directory '/build/proton-ge-custom/src/build'
make[1]: *** [../proton-ge-custom/Makefile.in:121: container-build] Error 2
make[1]: Leaving directory '/build/proton-ge-custom/src/build'
make: *** [../proton-ge-custom/Makefile.in:32: nested_make] Error 2

loathingkernel commented on 2022-08-28 16:20 (UTC) (edited on 2022-08-28 16:21 (UTC) by loathingkernel)

@LoKolbasz Do you have a log? Or do you remember which component failed? The current version built correctly in the CHROOT a few days ago, so I doubt there is anything missing, or this might be something new that I haven't encountered yet. Are you sure this isn't something local to your system?

LoKolbasz commented on 2022-08-28 15:57 (UTC)

I encountered a problem where the build failed because of missing capi2.0 libraries. Managed to resolve the issue by installing lib32-libcapi and libcapi from rhe AUR. They sould probably be added as make dependencies.

OS: Arch Linux x86_64

LibertyGM commented on 2022-07-20 15:45 (UTC)

@loathingkernel I read your post carefully, I don't know much about linux. I put "-j$(nproc)" in my PKGBUILD and it started to build on all kernels. I see your point.

loathingkernel commented on 2022-07-20 15:39 (UTC) (edited on 2022-07-20 15:45 (UTC) by loathingkernel)

@imLEGR

I think you didn't read my message at all. MAKEFLAGS or make -j$(nproc) will make logging incomprehensible. The number of build-jobs is passed through the SUBJOBS variable. The PKGBUILD will either pass the value from /etc/makepkg.conf or from nproc as shown here

If that doesn't work for you, look at your system's configuration. There is nothing this package should do. Feel free to do anything you like to the PKGBUILD locally, but adding MAKEFLAGS or make -j$(nproc) to the PKGBUILD here when it is not required and will cause issues, is non-sense.

LibertyGM commented on 2022-07-20 13:59 (UTC)

@loathingkernel

I mean you can add "-j$(nproc)" to the PKGBUILD file to build and then the package will build on all cores and it will not take hours. Right now it's building on one core and it's taking an unreasonable amount of time.

MAKEFLAGS="-j$(nproc)" doesn't help, proton-ge-custom is still building on one core. This is why we need to add "-j$(nproc)" to PKGBUILD.

« First ‹ Previous 1 .. 8 9 10 11 12 13 14 15 16 17 18 .. 34 Next › Last »