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.

Can confirm, installing lld fixed it for me as well.

Thanks @Dennis for finding the solution. Thanks @loathingkernel for helping with the issue as well; will be more descriptive when reporting issues in the future.

Fixed it: Digging into "src/build/src-wine/tools/winegcc/winegcc.c" I figured out that it looks for a very specific version of the linker ld, namely ld.lld (see line 359 in winegcc.c), which is provided by the package "https://archlinux.org/packages/extra/x86_64/lld/". After installing the lld package, the build succeeds on my system. It might be a good idea to add the lld package as a dependency. Perhaps that will help the Manjaro users as well.

@loathingkernel: Well, I posted the only error in the log and not the whole log and I did not think it would be necessary to state explicitly that I am on Arch while posting about something inside a repository named "Arch User Repository". I am also not doing anything special going about the build. I download the snapshot, I extract it, I run makepkg. I will continue trying to build and report if I can figure out how to fix and what's causing it.

@Dennis I consider it an insult and bad faith to dumb a badly formatted, information lacking log without providing any other details about an issue that has been already discussed in the past 2-3 pages of comments. If you have had looked at the comments then it would be clear that you should have mentioned at least that it is happening to you on Arch. Yes, I have seen that error, I have had discussions in this very comment space about that error. And I have already replied that I cannot reproduce it for the other few times. And I tried again, didn't happen either.

So yeah, I will suggest that you didn't do your due diligence before reporting it. The rest of it, about suggesting you are dumb or anything, it is your interpretation and not what I said.

@loathingkernel: The only thing fishy here seems to be your attitude. I did absolutely nothing to offend you and yet everything starting from your first reply is suggesting that I'm dense or stupid or whatever. Anyway, if you can't help, then don't respond but please refrain from throwing more suggestive/insultive "you're just too dumb" bullshit my way.

@Dennis, excuse me, but I did a rebuild today on a fully upgraded Arch system in a clean chroot, and I have done so the last 4 times this error has been reported. Somehow I doesn't manifest, not once. Every instance of this error so far has been from Manjaro users. I do not know how you are building it, where you are building it, and what the rest of the log looks like as you didn't post it. Also, if you had looked, you would see that request to not post logs but link to them, as in a pastebin-like service, so I doubt you read them before I mentioned it. Something is definately fishy here.

@loathingkernel: [dennis@DB2arch ~]$ distro Name: Arch Linux Version: rolling (n/a) Codename: n/a Excuse me but I did read the pinned message and I could not find any solution to the error in the existing comments. I did a full system upgrade just before attempting the build to make sure everything is up-to-date.

@Dennis, let me guess, Manjaro and you didn't bother to look at the rest of the comments nor the pinned message right?

Build fails for me while trying to build capi2032.dll.so. Any ideas what might be causing that and how to fix?

tools/winegcc/winegcc -o dlls/capi2032/capi2032.dll.so --wine-objdir . -m32 -fno-PIC -Wl,-z,notext \ -fasynchronous-unwind-tables -shared \ /mnt/RAM/proton-ge-custom/src/build/src-wine/dlls/capi2032/capi2032.spec dlls/capi2032/cap20wxx.o \ libs/port/libwine_port.a -ldl -L/mnt/RAM/proton-ge-custom/src/build/dst-gst_orc32/lib -L/mnt/RAM/proton-ge-custom/src/build/dst-gstreamer32/lib -L/mnt/RAM/proton-ge-custom/src/build/dst-gst_base32/lib -L/mnt/RAM/proton-ge-custom/src/build/dst-faudio32/lib -L/mnt/RAM/proton-ge-custom/src/build/dst-jxrlib32/lib -Wl,-rpath-link=/mnt/RAM/proton-ge-custom/src/build/dst-gst_orc32/lib -Wl,-rpath-link=/mnt/RAM/proton-ge-custom/src/build/dst-gstreamer32/lib -Wl,-rpath-link=/mnt/RAM/proton-ge-custom/src/build/dst-gst_base32/lib -Wl,-rpath-link=/mnt/RAM/proton-ge-custom/src/build/dst-faudio32/lib -Wl,-rpath-link=/mnt/RAM/proton-ge-custom/src/build/dst-jxrlib32/lib -Wl,-O1,--sort-common,--as-needed winegcc: Could not find ld make[3]: *** [Makefile:20626: dlls/capi2032/capi2032.dll.so] Error 2 make[3]: *** Waiting for unfinished jobs.... make[3]: Leaving directory '/mnt/RAM/proton-ge-custom/src/build/obj-wine32' make[2]: *** [../proton-ge-custom/build/makefile_base.mak:723: /mnt/RAM/proton-ge-custom/src/build/.wine-build32] Error 2 make[2]: Leaving directory '/mnt/RAM/proton-ge-custom/src/build' make[1]: *** [../proton-ge-custom/build/makefile_base.mak:89: container-build] Error 2 make[1]: Leaving directory '/mnt/RAM/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...

The new version retargeted the the dxvk submodule and it seems to be fixed now.