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.

@qontinuum yeah, the issue with faudio is also the one blocking the update. Adding it as an Arch native dependency won't work, as FAudio on Proton needs FFMpeg support, something that the Arch library lacks for the lib32 package, and can't be used as a drop-in replacement. I have been trying to tackle this very issue for the past few days but I have had no success.

EDIT: The issue is due to lib32-sdl2 lagging behind in the repos. I will withhold updating it until the version in the repos has been updated to 2.0.16

@qfettes check the pinned message, may help to read those

@loathingkernel: I am getting an error with faudio when compiling:

configure: error: libFAudio 32-bit development files not found, XAudio2 won't be supported.
This is an error since --with-faudio was requested.

It isn't fixed by adding lib32-faudio as a dependency but I was able to compile older versions on the package (I am currently running version 1:6.14.GE.2-2).

Installing with yay aur helper yields the following error:

Could not find all required packages:
    meson=0.58.1

@loathingkernel nah, seems to be fixed now.
sry for the false alarm.

@MisterNoNameLP this has been fixed, are you still getting an error?

if anyone still get the error: > ninja: fatal: invalid -j parameter here is a quick and dirty workaround. it basically just removes the -j flag from all ninja calls in a specific terminal.

Dependencies:
lua

(replace PATH_TO_DIR with any path u want to use)
open a terminal and do the following:

mkdir PATH_TO_DIR   #create new dir
touch PATH_TO_DIR/ninja   #create a file named "ninja"
chmod +x PATH_TO_DIR/ninja   #make the file "ninja" executable
export PATH="ABSOLUTE_PATH_TO_DIR:$PATH"   #adds the dir to the $PATH variable, so our file gets called instead of ninja

then open PATH_TO_DIR/ninja with any editor u like and add the following:

#!/bin/lua
--calls ninja witout the -j flag.

local args = ""
for i, a in pairs(arg) do
    if i > 0 then
        args = args .. a .. " "
    end
end
args = args:gsub("-j", "")

return os.execute("/usr/bin/ninja " .. args)

this script calls ninja but without any -j flag.

that should "fix" the problem. but u have to call export PATH="ABSOLUTE_PATH_TO_DIR:$PATH" everytime u are trying to build the package in a new terminal.

ps.: i know that is pretty crappy. but it seems to work in this case so.. shrug

Yeah that is a good point.

@loathingkernel, it should at least not fail with what is "default" in Arch. So probably a if [[ "$MAKEFLAGS" =~ -j\ *([^\ ]+) ]]; then SUBJOBS="${BASH_REMATCH[1]}" else SUBJOBS="$(nproc)"; fi would be welcomed...

I do not want to ignore the makeflags or the buildflags as a whole (although I will concede that I am already overriding a lot of those), but MAKEFLAGS being empty is causing the issue. Ignoring makeflags through options is not going to fix the issue as described in the previous comment (I will still have to specify something there to avoid congestion) and building with 1 job is going to take a very long time.

You can configure the $CHROOT/root to uncomment MAKEFLAGS or I can hard-code $(nproc) as an argument to SUBJOBS. Honestly I have no better solution at this point.

@loathingkernel it's a freshly clean chroot, so MAKEFLAGS is still commented in /etc/makepkg.conf. (I put an echo in prepare to spy it anyway, and Arch's default seems to be indeed empty).

What about using options+=(!buildflags !makeflags) ?

More useful in its negative form !buildflags with select packages that have problems building with custom buildflags.

More useful in its negative form !makeflags with select packages that have problems building with custom makeflags such as -j2 (or higher).