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.

@ayyash07 thanks for the patch, but updating the patch isn't the issue. I do not have access to my git repos that track my proton patches at this moment. I won't introduce changes that I am not tracking. Updating will have to wait until I am back to my main dev computer.

Fixed patch for 8-11: 0001-AUR-Pkgbuild-changes.patch

https://pastecode.io/s/qc4rskhw

@niobium93 Yes, there should be, the same problem for vkd3d-proton was fixed at some point by using -static -static-libgcc instead of just -static-libgcc but this is not possible for vkd3d because it leads to vulkan discoverability issues at configure. Presently I am not aware of a solution to force the linker to do what it should.

The disparity between your experience with 64bit and mine makes this problem even more perplexing. I cannot find any indication in my local 64bit binaries that they link to libgcc as objdump -x doesn't reveal a dependency. I have no idea why this disparity might be.

I will be copying them them for the 64bit too for now and call it a day until a better solution presents itself. Thanks for testing Hotshot, the 64bit game I tried locally with wined3d (XCOM2) didn't require them.

@loathingkernel here's a snippet from the proton log for Hotshot Racing after the workaround, showing the libraries being loaded:

2841.463:012c:0130:trace:loaddll:build_module Loaded L"C:\\windows\\system32\\libwinpthread-1.dll" at 00000002E3650000: native
2841.463:012c:0130:trace:loaddll:build_module Loaded L"C:\\windows\\system32\\libgcc_s_seh-1.dll" at 00000001E0140000: native
2841.463:012c:0130:trace:loaddll:build_module Loaded L"C:\\windows\\system32\\libvkd3d-shader-1.dll" at 00000002FCA80000: native
2841.463:012c:0130:trace:loaddll:build_module Loaded L"C:\\windows\\system32\\libvkd3d-1.dll" at 00000002D64D0000: native
2841.463:012c:0130:trace:loaddll:build_module Loaded L"C:\\windows\\system32\\wined3d.dll" at 0000000367600000: builtin
2841.463:012c:0130:trace:loaddll:build_module Loaded L"C:\\windows\\system32\\d3dcompiler_47.dll" at 000000027CF30000: builtin
2841.463:012c:0130:trace:loaddll:build_module Loaded L"C:\\windows\\system32\\d3dx11_43.dll" at 00000002DBAF0000: builtin

@loathingkernel Linking /usr/i686-w64-mingw32/bin/libgcc_s_dw2-1.dll and /usr/i686-w64-mingw32/bin/libwinpthread-1.dll into .../steamapps/compatdata/70/pfx/drive_c/windows/syswow64/ does fix Half-Life.

Hotshot Racing, however, is a 64-bit game.

file HotshotRacing.exe 
HotshotRacing.exe: PE32+ executable (GUI) x86-64, for MS Windows, 9 sections

On my end 64-bit libvkd3d suffers from the same issue. In that case linking /usr/x86_64-w64-mingw32/bin/libgcc_s_seh-1.dll and /usr/x86_64-w64-mingw32/bin/libwinpthread-1.dll into ...steamapps/compatdata/609920/pfx/drive_c/windows/system32/ is the correct workaround.

There has got to be a way to force the compiler to statically link those libraries, though...

@niobium93 I have investigated the issue and there is no apparent fix to it. The 32bit vkd3d dll always links to two specific functions (__udivid3 and __umoddiv3) provided by libgcc_s_dw2-1.dll no matter what linking options I use. The 64bit library doesn't link to anything, it is properly static.

I think I will modify the proton script to copy the required dlls into the prefix. Can you test your cases after copying /usr/i686-w64-mingw32/bin/libgcc_s_dw2-1.dll and /usr/i686-w64-mingw32/bin/libwinpthread-1.dll into drive_c/windows/syswow64 in the affected prefixes?

@loathingkernel a couple of test cases for when you have time: Half-Life which loads ddraw.dll and Hotshot Racing which loads d3dx11_43.dll. Both those libraries load wined3d.dll and in turn libvkd3d-1.dll.

@niobium93 They added the old vkd3d at some point to the build procedure so there must be a reason for that, although I am not aware of it. Maybe I could disable it through wine's configure and see what happens.

I need to find time and a test case though.

@loathingkernel mingw-w64-gcc is always installed on my system, so no. Apps running in proton have no way of knowing they could find libgcc_s_dw2-1.dll in /usr/i686-w64-mingw32/bin/. It would probably work if you symlinked or copied it into your prefix next to libvkd3d-1.dll, but this isn't a good solution as every user would have to do this manually for every game what uses wined3d in any way. This is why so many libraries in proton statically link so many things. I'm not sure if the old vkd3d is even necessary. Protons Makefile.in specifically tells wines configure to use it:

WINE_CONFIGURE_ARGS64 = --enable-win64 \
  VKD3D_PE_CFLAGS="-I$(VULKAN_HEADERS_DST64)/include -I$(VKD3D_DST64)/include/vkd3d" \
  VKD3D_PE_LIBS="-L$(VKD3D_DST64)/bin -l:libvkd3d-1.dll -l:libvkd3d-shader-1.dll"

Regular wine packages like the wine package in Arch and things like wine-ge-custom don't do this, don't depend on the vkd3d package and don't build libvkd3d-1.dll so maybe this isn't actually needed?

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