Arch Linux User Repository

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

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.

After doing some digging it appears that gcc 11.1 has not made its way to the stable branch for Manjaro. It is still in staging. I updated gcc and relevant libraries to 11.1 from the staging branch and reran the AUR build, however it appears I'm now getting a git reference error when cloning dxvk. How odd. Next step would be either building gcc 11.1 myself or waiting for it to show up in stable. Busy holiday weekend for me so probably going to wait a few days. Strongly considering making the switch to Arch though. lol.

@loathingkernel Thanks for your help and insight on this. I'll report back next week with my findings for any Manjaro users who might be following along.

@stdinUsrError Mainline Arch is on core/gcc 11.1.0-1 and community/mingw-w64-gcc 10.2.0-2 so there is a discrepancy there. I do not know what packages had to be rebuilt due to gcc 11 but there is definitely something broken with Manjaro. That is not something I can do anything about. Wine is not and it should not be required. Also it should not be conflicting in any way. That is why I asked and it seems that it doesn't based on yours and mine testing alike.

@loathingkernel Pacman reports 10.2.0-2 for mingw-w64-gcc and 10.2.0-6 for gcc.

Wine is not currently installed but I have tried the AUR build separately with both wine and wine-staging installed as well. As far as I could tell results did not differ. Pacman reports version 6.8-1 for both currently.

@stdinUsrError If I had to guess, it has to do with Manjaro holding some package versions back, but they do not hold everything. They might have held mingw-gcc or gcc and created an ABI incompatibility. It might be something else. What you could post here are the versions of mingw-gcc, gcc, and if wine is installed, the version of that (I have a hunch that I want to test).

@loathingkernel Sorry I didn't think to mention my distro, thats my bad. You mentioned pamac so I tried building with yay, same error. Any thoughts on what the "could not find ld" error might point to so I can work on figuring out what's going on on my end?

@stdinUsrError You can just run makepkg after the cloning this AUR repo.

I did have a feeling you were on Manjaro as well as the other people that reported this issue (pamac in the logs). I don't know what shitty things the distro you are using might be doing but I do not test against them. And I sure as hell won't try to guess what they might be doing wrong. It builds just fine on mainline Arch.

The least you can do is mention it when reporting the issue, the build takes quite some time and resources and every time someone reports an issue I try to reproduce it. I consider it common courtesy to mention it and not letting me guess.

@loathingkernel Negative. There's a lot going on here and tbh I'm not sure how comfortable I am building it on my own. I could probably give it a shot later tonight though. I'm on Manjaro.

@stdinUsrError @biorpg Has either of you tried building without an AUR helper and what distro are you on?

I too am seeing the "winegcc: Could not find ld" error every time when it gets to the dlls. My log output looks identical to biorpg's with it failing when it hits capi2032.dll.so.

I've double checked all my dependencies and as far as I can tell everything that needs to be is there. I've tried updating and removing and reinstalling multiple times. Build has been failing I believe since the 6.5 update. All steam proton-ge prefixes have been removed per GE's recommendations. I'm at a loss for how to proceed as I'm not really finding anything online about how to handle this error.

I am also getting the 'winegcc: Could not find ld' error.

tools/winegcc/winegcc -o dlls/capi2032/capi2032.dll.so --wine-objdir . -m32 -fno-PIC -Wl,-z,notext \
  -fasynchronous-unwind-tables -shared \
  /var/tmp/pamac-build-biorpg/proton-ge-custom/src/build/src-wine/dlls/capi2032/capi2032.spec \
  dlls/capi2032/cap20wxx.o libs/port/libwine_port.a -ldl -L/var/tmp/pamac-build-biorpg/proton-ge-custom/src/build/dst-gst_orc32/lib -L/var/tmp/pamac-build-biorpg/proton-ge-custom/src/build/dst-gstreamer32/lib -L/var/tmp/pamac-build-biorpg/proton-ge-custom/src/build/dst-gst_base32/lib -L/var/tmp/pamac-build-biorpg/proton-ge-custom/src/build/dst-faudio32/lib -L/var/tmp/pamac-build-biorpg/proton-ge-custom/src/build/dst-jxrlib32/lib -Wl,-rpath-link=/var/tmp/pamac-build-biorpg/proton-ge-custom/src/build/dst-gst_orc32/lib -Wl,-rpath-link=/var/tmp/pamac-build-biorpg/proton-ge-custom/src/build/dst-gstreamer32/lib -Wl,-rpath-link=/var/tmp/pamac-build-biorpg/proton-ge-custom/src/build/dst-gst_base32/lib -Wl,-rpath-link=/var/tmp/pamac-build-biorpg/proton-ge-custom/src/build/dst-faudio32/lib -Wl,-rpath-link=/var/tmp/pamac-build-biorpg/proton-ge-custom/src/build/dst-jxrlib32/lib  -Wl,-O1,--sort-common,--as-needed 
winegcc: Could not find ld
make[3]: *** [Makefile:20944: dlls/capi2032/capi2032.dll.so] Error 2
make[3]: *** Waiting for unfinished jobs....
make[3]: Leaving directory '/var/tmp/pamac-build-biorpg/proton-ge-custom/src/build/obj-wine32'
make[2]: *** [../proton-ge-custom/build/makefile_base.mak:723: /var/tmp/pamac-build-biorpg/proton-ge-custom/src/build/.wine-build32] Error 2
make[2]: Leaving directory '/var/tmp/pamac-build-biorpg/proton-ge-custom/src/build'
make[1]: *** [../proton-ge-custom/build/makefile_base.mak:89: container-build] Error 2
make[1]: Leaving directory '/var/tmp/pamac-build-biorpg/proton-ge-custom/src/build'
make: *** [../proton-ge-custom/build/makefile_base.mak:20: nested_make] Error 2
==> ERROR: A failure occurred in build().
    Aborting...

It has failed like this 3 or 4 times now, and each time it seems to fail on a different target, but always within the dlls/ folder.

>make[3]: *** [Makefile:20944: dlls/capi2032/capi2032.dll.so] Error 2