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.

@imLEGR

The issue with concurrent jobs in regard to the wine component had nothing to do with the kernel, it was an issue with mingw-w64-binutils. The situation with that package has been fixed and this package builds with concurrent jobs just fine. I am unsure what you refer to in regard to the kernel and how that affects the number of jobs this package is built with.

Furthermore, adding MAKEFLAGS in the PKGBUILD disregards makepkg.conf, so that is a regression, not a feature. I am not going to force anyone who doesn't want to do so to build with all their cores and has configured makepkg to do so.

Also adding that flag to the PKGBUILD will make make to run multiple targets concurrently, basically interleaving the build process of multiple components together, which is bad for logging the process and understanding where a failure came from. This package uses the SUBJOBS env variable to pass the number of jobs each components should be built with, which adheres to either the makepkg configuration or the result of $(nproc) if the former is not configured.

Did you look at the PKGBUILD before contacting whoever you might have contacted about this? Which I still don't see how it is applicable to this PKGBUILD.

Hello loathingkernel, I have contacted the maintainers of the necessary packages to build and now proton-ge-custom can be built on all kernels using MAKEFLAGS="-j$(nproc) " or MAKE="-j$(nproc) ".

Now there will be no error when compiling and you can build on all kernels.

Please add "-j$(nproc)" to PKGBUILD.

after delete 0002-RevertMe-Use-one-job-for-autoconf-targets-because-of.patch does not compile in clean chroot

@RubenKelevra Yes, I do have issues with it, and I do not really need to elaborate further, since there is a comment history that can tell you why it is a bad idea, but here is the gist.

You set one specific platform in your PKGBUILD and I replaced it with a dynamic one.

And there is a very good reason for that. native in the case of this package doesn't mean "better" nor "more performant". There have been reports where targeting more recent instruction sets had negative effects. Forcing native to anyone who doesn't know better but just found your package is not a good thing. It is even malicious given the time it takes to build.

The point of the package is just, that I want to build packages with native on my machines

This is the very definition of your personal PKGBUILD, it fits you, it doesn't fit anyone else for reasons I described above.

and I share the package on the AUR since there may be other people wanting to do the same.

If they want to do the same they can use edit the PKGBUILD themselves. It is almost like signing a waiver, when you edit it you have read the comments in the PKGBUILD and you have accepted the risks. In case you provide it readily made, it means you have to support it, and I don't want to support building with native, people who understand the risks can do that without any hand-holding.

Still having problems with that? If so - can you elaborate? :)

Yes I still do, and especially with the condescending smiley face.

My question was just geared towards the fact that paru seems to "think" that the gits do change the code used in this repository on each and every commit.

According to the creator of paru, because they are not pinned, but I firmly believe that they are wrong in that regard and I have commented on why here

Oh, finally. Seems I had to choose stable toolchain as default AND install i686 target. Now it builds.

The AUR is not a personal repository, and this looks like a change that would be useful only to you. This should be handled in some other private to you way and not in the AUR.

Not sure what on a natively building package is "personal". You set one specific platform in your PKGBUILD and I replaced it with a dynamic one. As long as you build it on the same machine it will be still reproduceable.

My question was just geared towards the fact that paru seems to "think" that the gits do change the code used in this repository on each and every commit.

The point of the package is just, that I want to build packages with native on my machines and I share the package on the AUR since there may be other people wanting to do the same. If not – this doesn't hurt.

Still having problems with that? If so - can you elaborate? :)

While I agree that march=native is not suitable for AUR without description on which architecture it was build on, in general such a march=CPU architecture package has some value for people on newer architectures.

The march=native is part of the description of the package, so moving the build package from one computer to the next doesn't make much sense in this case. :)

@lem0nify rustup target install i686-unknown-linux-gnu

Still no idea how to build it with rust installed by rustup without installing lib32-rust-libs ?

People are free to try any optimizations they want, that is why I packaged this software in this way. One case could be made for x86_64_v3 but even then, editing the pkgbuild is simple, there is no need for iffy automation through package names. It's Arch ffs.

@ms178 AVX and AVX2 from my testing do not offer any performance benefit, at all, they even have had the opposite effect in some cases. Also many 32bit games are broken with these flags enabled.