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.

@niobium93 This reminds me a of problem I have encountered so I think I could investigate it further too. Is it resolved if mingw-w64-gcc is installed in the system (it provides libgcc_s_dw2-1.dll). I could elevate it to a regular dependency instead of a makedep if it does. I would prefer static linking too but currently I don't have time to get too deep into it.

I believe libvkd3d-1.dll and libvkd3d-shader-1.dll are linked incorrectly in this package. They both depend on libgcc_s_dw2-1.dll which isn't present. Probably it was meant to be statically linked, but wasn't. This is a problem as the vkd3d dlls are loaded by wined3d.dll, which is in turn loaded by things like DDRAW.dll and the various d3dcompiler* dlls. All of those fail - meaning any game that uses DirectDraw, old versions of Direct3D not covered by DXVK and any game that doesn't ship it's own d3dcompiler dll fail to run.

Example of the issue:

16723.103:012c:0130:err:module:import_dll Library libgcc_s_dw2-1.dll (which is needed by L"C:\\windows\\system32\\libvkd3d-shader-1.dll") not found
16723.104:012c:0130:err:module:import_dll Library libvkd3d-shader-1.dll (which is needed by L"C:\\windows\\system32\\libvkd3d-1.dll") not found
16723.104:012c:0130:err:module:import_dll Library libgcc_s_dw2-1.dll (which is needed by L"C:\\windows\\system32\\libvkd3d-1.dll") not found
16723.105:012c:0130:err:module:import_dll Library libvkd3d-1.dll (which is needed by L"C:\\windows\\system32\\wined3d.dll") not found
16723.106:012c:0130:err:module:import_dll Library libgcc_s_dw2-1.dll (which is needed by L"C:\\windows\\system32\\libvkd3d-shader-1.dll") not found
16723.107:012c:0130:err:module:import_dll Library libvkd3d-shader-1.dll (which is needed by L"C:\\windows\\system32\\wined3d.dll") not found
16723.107:012c:0130:err:module:import_dll Library wined3d.dll (which is needed by L"C:\\windows\\system32\\DDRAW.dll") not found
16723.107:012c:0130:err:module:import_dll Library DDRAW.dll (which is needed by L"Z:\\home\\andrius\\.local\\share\\Steam\\steamapps\\common\\Half-Life\\hw.dll") not found

I've looked at Makefile.in and it does set VKD3D_LDFLAGS = -static-libgcc $(CROSSLDFLAGS), but I guess that isn't enough.

To be clear this is regarding wines vkd3d that wined3d uses, not vkd3d-proton, which works fine.

/usr/share/steam/compatibilitytools.d/proton-ge-custom/files/lib/wine/i386-windows/ddraw.dll
/usr/share/steam/compatibilitytools.d/proton-ge-custom/files/share/default_pfx/drive_c/windows/system32/ddraw.dll
/usr/share/steam/compatibilitytools.d/proton-ge-custom/files/share/default_pfx/drive_c/windows/syswow64/ddraw.dll
/usr/share/steam/compatibilitytools.d/proton-ge-custom/files/lib64/wine/x86_64-windows/ddraw.dll

ddraw.dll exists in the package, I don't know why you are facing this issue or if it is even relevant to the package itself.

I would like to note that Half-Life fails to run on version 8x. I did not notice this when using any older versions of proton.

At runtime, an error about hw.dll missing appears.

With the debug logs enabled, I discovered that ddraw.dll is missing which was a dependency of hw.dll ...

I manually added ddraw.dll to the half-life folder and added a dll override into the winecfg using protontricks and that resolved my issue.

@loathingkerne Not trying to rush anything, but I sent the log, did you receive it?

@vedranmiletic You can send the log created with PROTON_LOG=1 to my email address and I will take a look at it.

I believe this package told upon upgrade to report issues here in case official build of Proton GE runs the game, but this package doesn't.

I am using Garuda Linux, Steam installation as default on KDE Dragonized Gaming Edition. Yesterday I tested eFootball 2023 on official build of GE-Proton8-3 and it runs successfully. At the same time, running eFootball 2023 on this package built from Chaotic AUR results in the game crashing on startup. Is this an issue that is interesting to you? If yes, what details can I provide?

@ms178 That's just demoting the (valid) error into a warning. It is reasonable for it to fail later on, as if I am correct, this has to do with the removed two-stage overload resolution. What makes this tricky is that the problem happens in a C header, when used to compile a C++ program.

I think I have solved it, I will do run a few complete compilations and test it before updating the AUR package.

@pattlefort @mihalycsaba The rpcasync error can be worked around by ignoring the warning-treated-as-error with "-Wno-error=changes-meaning" in your CFLAGS, but the build still fails later on with a header error in steamworks_sdk_142. It is also probably due to a breaking change in GCC 13.

On the bright side, GCC 13 seems to have fixed an issue causing very long compile times in a single file that took over 40 Minutes with my custom CFLAGS.

I am aware of the issue but I am still investigating it. So far I believe it is due to gcc 13 and some changes to -std=c++17. The failure is in building steam.exe. I do not have a solution at this moment.

In the meantime, I have compiled packages, which seem to work fine still here. https://github.com/loathingKernel/PKGBUILDs/releases