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.

@loathingkernel whatever it was that bug with memleak, is gone in the current version. Also, thanks for all the support, will schedule it to build automatically...

@orlfman Two different issues and I require information of both of them, cause they should not be happening.

For the first one, I decided to use python-virtualenv to install it locally from PyPI with python-pip because there are dependency issues with the afdko package on AUR. But as I just realized I forgot to add python-pip as a dependency, so that is an easy fix.

For the second one, since I cannot test, can you provide any more information that you can think of? It could be linking to the wrong libraries during compilation. Can you point me to a relevant issue in github, a mailing list or something to find the exact component that fails? Local tests with some games have media foundation working, but since there are many possible codecs, your issue might not manifest with the games I play/test. Your cflags look fine to me.

if anyone else is failing to build due to "makeotf" not found, you need afdko. which is in the aur. and afkdo needs python-pip installed as well. its not pulled in either.

edit: for some odd reason, the compile version doesn't have media foundation working. with the bin version off GE site and the from here in the AUR, media foundation works. but compiling it doesn't. i used the outer worlds to test. could this be caused by cflags? these are my cflags: -march=skylake -O2 -pipe -fno-plt

So, you were correct about the widl dependency. Now mingw-w64-tools is required although wine could satisfy it too.

I still have not figured out the memory leak issue. I am just speculating, but could it be a very high amount of MAKEJOBS (I assume because of the 64gb of memory you mentioned, those machines have a high thread count)?

OK, I just rebuilt it to test the upstream opts, and it was fine. I am rebuilding it now to keep a log to compare. Will report back afterwards.

They changed vkd3d to be built by mingw to produce a dll similar to dxvk.

It required it, but looking at the logs, seems like it wasn't used.

but what do you mean by struggling without memory?

It grows in memory usage until the kernels kill it... (Really, for half a minute I see my memory usage grow up to 64Gb)

similar to building on a tmpfs

Yep, that what I thought at first, then I tried building in the disk, and the result was the same. It's a mingw process, and it's kept in "D" state after failing (and there it stays until I hard halt the machine):

build-user  367354  0.0  0.0  69708 13232 ?        D    15:27   0:00 /usr/lib/gcc/x86_64-w64-mingw32/10.2.0/cc1 -quiet -I dlls/d3dx9_43 -I ../../proton-ge-custom/wine/dlls/d3dx9_43 -I ../../proton-ge-custom/wine/dlls/d3dx9_36 -I include -I ../../proton-ge-custom/wine/include -I ../../proton-ge-custom/wine/include/msvcrt -D_REENTRANT -D __WINESRC__ -D D3DX_SDK_VERSION=43 -D _UCRT -D WINE_CROSS_PE -D _FORTIFY_SOURCE=2 ../../proton-ge-custom/wine/dlls/d3dx9_36/skin.c -quiet -dumpbase skin.c -mcx16 -march=nocona -mtune=core-avx2 -mno-avx -mfpmath=sse -auxbase-strip dlls/d3dx9_43/skin.cross.o -gdwarf-2 -gstrict-dwarf -g -O2 -Wall -Wdeclaration-after-statement -Wempty-body -Wignored-qualifiers -Wno-packed-not-aligned -Wshift-overflow=2 -Wstrict-prototypes -Wtype-limits -Wunused-but-set-parameter -Wvla -Wwrite-strings -Wpointer-arith -Wlogical-op -Wabsolute-value -Wformat=0 -Wformat-overflow=1 -Wnonnull -fwrapv -fno-strict-aliasing -o /tmp/ccYgILfS.s

(I've been building a bunch of packages for the last 2yrs, and never seen this before)

It's missing widl (executable) to build vkd3d;

It shouldn't be needing it at all. They changed vkd3d to be built by mingw to produce a dll similar to dxvk. Or it should be using the one from the included wine. Does it complain about it? If so there should be an issue somewhere.

There is a process leaking memory

I have no encountered that, but what do you mean by struggling without memory? As far as I understand this seems to me similar to building on a tmpfs without enough allocated space, but also different enough from it to not be sure about it at all.

It's missing widl (executable) to build vkd3d;

There is a process leaking memory while compiling wine/dlls/d3dx9_36/skin.c, no clue why, but it generates a valid object before struggling without memory... The worst part is Linux trying to "core dump" a process as large as your memory. (This happened in two different chaotic's clusters)

Ok, thanks @loathingkernel, I'll unset CXX/CFLAGS just in proton-ge-custom builds...

@PedroHLC, I am referring to proton's upstream. In this package (as well as proton-native) I am patching the makefile with the following

-OPTIMIZE_FLAGS := -O2 -march=nocona $(call cc-option,$(CC),-mtune=core-avx2,) -mfpmath=sse
+CFLAGS ?= -O2 -march=nocona $(call cc-option,$(CC),-mtune=core-avx2,)
+OPTIMIZE_FLAGS := $(CFLAGS) -mfpmath=sse

Upstream proton uses -march=nocona with optional -mtune=core-avx2. My patch changes that and takes the CFLAGS from makepkg. But that might not be what we want if -march=x86_64 is specified in makepkg.conf because it is lesser than nocona. I would suggest to either unset CFLGAGS and CXXFLAGS to use the defaults (not sure it will pass it to all sub-makes properly), or use a proton specific makepkg.conf with -O2 -march=nocona -mtune=core-avx2 as CFLAGS/CXXFLAGS

Edit: I was wrong, unsetting them won't work, because they will be set again later for -mno-avx (I don't want to use conditionals in the PKGBUILD to accommodate for unset CXX/CFLAGS), it is better to hard-code them as above if you want to go that route.