Arch Linux User Repository

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"

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.

@Xakurinha32 Kaldi's build system is using an outdated method of finding CUB headers. (There's a CMake warning before that error about it.) It should be inspecting the CUDA_PATH system variable and look in $CUDA_PATH/include, but effectively only looks in /usr/include. Because Arch's CUDA package puts its files in /opt/cuda Kaldi can't find cub/cub.h.

To work around this simply ln -st /usr/include $CUDA_PATH/include/cub.

Alternatively the PKGBUILD here could patch Kaldi's build system to pass -DCUB_INCLUDE_DIR=$CUDA_PATH/include to cmake...

@Xakurinha32 https://aur.archlinux.org/packages/proton-ge-custom?O=30#comment-930706

I got the following error:

CMake Error at /usr/share/cmake/Modules/FindPackageHandleStandardArgs.cmake:230 (message):
  Could NOT find CUB (missing: CUB_INCLUDE_DIR)
Call Stack (most recent call first):
  /usr/share/cmake/Modules/FindPackageHandleStandardArgs.cmake:600 (_FPHSA_FAILURE_MESSAGE)
  cmake/FindCUB.cmake:17 (find_package_handle_standard_args)
  CMakeLists.txt:200 (find_package)

https://www.mpg123.de/#2023-09-27 fixed it, managed to build successfully

Same issue exists with gstreamer from Arch when trying to build it based on the newer mpg123. This will have to wait for a fix from the gstreamer project itself.

Downgrading mpg123 to version 1.31.3 fixes the issue.

@mihalycsaba no, I monitor changes in the Makefiles, since they are patched to make it build. Your issue is probably the same one patlefort reported, between the time I tested building the package, and now mpg123 and lib32-mpg123 have been updated in the Arch repos. The issue is with that dependency and I need to fix the package itself.

imported build changes from upstream proton

This is from the release notes, could this have something to do with it?

I had no problems building the previous version, didn't change or install anything since. Btw thanks for your work, I spent a few hours trying to figure out what's wrong, but I don't know nearly enough to figure this out.

@patlefort now, I know that you indeed build it in a clean chroot. But how did my CI build it correctly then? This sadly will have to wait because my dev machine is currently down for maintenance.