Arch Linux User Repository

There are patches here to address these gcc 15 failures, https://github.com/CachyOS/proton-cachyos/tree/cachyos_10.0_20250430/main/patches

I am not sure if these cover everything as I am working on rebasing on top of proton 10

@TRex these issues are happening because of the GCC 15 upgrade. I would suggest downgrading GCC and Mingw for now until this is resolved upstream. It's not just GLSlang, I tried to fix it and there are multiple issues in openfst and Wine and likely other places too.

pacman -U https://archive.archlinux.org/packages/l/lib32-gcc-libs/lib32-gcc-libs-14.2.1%2Br753%2Bg1cd744a6828f-1-x86_64.pkg.tar.zst pacman -U https://archive.archlinux.org/packages/m/mingw-w64-gcc/mingw-w64-gcc-14.2.0-3-x86_64.pkg.tar.zst

diff --git a/proton-cachyos/PKGBUILD b/proton-cachyos/PKGBUILD
index 00339e80..fd5e5d8d 100644
--- a/proton-cachyos/PKGBUILD
+++ b/proton-cachyos/PKGBUILD
@@ -35,7 +35,7 @@ depends=(
   desktop-file-utils
   fontconfig      lib32-fontconfig
   freetype2       lib32-freetype2
-  gcc-libs        lib32-gcc-libs
+  gcc14-libs      'lib32-gcc-libs<15.0.0'
   gettext         lib32-gettext
   lapack          lib32-lapack
   libgudev        lib32-libgudev
@@ -57,7 +57,7 @@ depends=(
 depends+=(
   wayland         lib32-wayland
 )
-makedepends=(autoconf bison perl flex mingw-w64-gcc
+makedepends=(autoconf bison perl flex 'mingw-w64-gcc<15.0.0'
   git
   afdko
   alsa-lib              lib32-alsa-lib
@@ -131,8 +131,8 @@ _make_wrappers () {
         for l in ar ranlib nm; do
             ln -s /usr/bin/gcc-$l wrappers/${_opt[0]}-pc-linux-gnu-$l
         done
-        for t in gcc g++; do
-            install -Dm755 /dev/stdin wrappers/${_opt[0]}-pc-linux-gnu-$t <<EOF
+        for t in gcc-14 g++-14; do
+            install -Dm755 /dev/stdin wrappers/${_opt[0]}-pc-linux-gnu-${t%%-14} <<EOF
 #!/usr/bin/bash
 $(which ccache 2> /dev/null) /usr/bin/$t ${_opt[1]} "\$@"
 EOF

This doesn't actually work though because of some issue with gcc-libs:

/usr/bin/gcc-14 -m32 sanitycheckc.c -o sanitycheckc.exe -ffunction-sections -fdata-sections -fno-omit-frame-pointer -s -O2 -march=native -mtune=core-avx2 -pipe -fno-semantic-interposition -mno-avx512f -mfpmath=sse -fwrapv -fno-strict-aliasing -ffile-prefix-map=/home/aur/CachyOS-PKGBUILDS/proton-cachyos/src/build/src-dav1d=. -mstackrealign -ffunction-sections -fdata-sections -fno-omit-frame-pointer -s -O2 -march=native -mtune=core-avx2 -pipe -fno-semantic-interposition -mno-avx512f -mfpmath=sse -fwrapv -fno-strict-aliasing -ffile-prefix-map=/home/aur/CachyOS-PKGBUILDS/proton-cachyos/src/build/src-dav1d=. -mstackrealign -D_FILE_OFFSET_BITS=64 -Wl,-O1,--sort-common,--as-needed
/usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-pc-linux-gnu/14.2.1/libgcc.a when searching for -lgcc
/usr/bin/ld: cannot find -lgcc: No such file or directory
/usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-pc-linux-gnu/14.2.1/libgcc_s.so.1 when searching for libgcc_s.so.1
/usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-pc-linux-gnu/14.2.1/libgcc_s.so.1 when searching for libgcc_s.so.1
/usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-pc-linux-gnu/14.2.1/libgcc.a when searching for -lgcc
/usr/bin/ld: cannot find -lgcc: No such file or directory
collect2: error: ld returned 1 exit status

In file included from /pkg/src/build/src-glslang/SPIRV/SpvPostProcess.cpp:46: /pkg/src/build/src-glslang/SPIRV/SpvBuilder.h:236:30: error: ‘uint32_t’ has not been declared 236 | Id makeDebugLexicalBlock(uint32_t line);

I already went through building in docker as described below (the quality of this docker image isn't really up to the job) and still got this error.

I did start to create an issue on github, but it's pointless if the root cause sits in the aur package.

@Alucard Due to unforeseen circumstances I didn't get the time to reply. Would you mind opening a GH issue in https://github.com/CachyOS/proton-cachyos with your findings so we can track it?

That being said, as you have already found out, -mpreferred-stack-boundary is already set in Maakefile.in, albeit it shouldn't be required as DXVK's build system now sets it by default for its 32bit libraries too. I was about to suggest either using -mprefer-avx128 or -mno-avx512f. We would like at least work around these issues, if not actually fix them, so we can include a znver4 build in CachyOS too, but due to HW availability I am not able to do it myself. Right now we are using the x86_64_v3 binaries for znver4 repos.

Sorry, I see now that preferred-stack-boundary is already included in the proton-cachyos source Makefile.in, but on my system it still crashes when compiling with march=znver4. I think I solved it by changing just DXVK (both 32 and 64 bit) to compile with -mno-avx512f.

Hello! Coming from proton-ge-custom, I built this with march=znver4 today and Elite Dangerous crashed after the opening logo, but when I rebuilt with march=znver3, it worked. If I'm seeing this right then I don't believe this package has the preferred-stack-boundary patch that proton-ge-custom did? Is it possible to add something similar?

No idea how long this link will work for but this is the patch I'm referring to: https://aur.archlinux.org/cgit/aur.git/tree/0008-build-Stop-forcing-mno-avx-for-32bit-libraries.patch?h=proton-ge-custom

Thank you!

@loathingkernel i only use paru, that didn't help. I'll look into the clean chroot.

Edit: ok, the clean chroot didn't help. As per the upstream developer, I ended up using their docker-makepkg package (https://github.com/CachyOS/docker-makepkg) and ran the command directly inside the cloned aur repo: time docker run --name dockerbuilder -e EXPORT_PKG=1 -e SYNC_DATABASE=1 -v $PWD:/pkg cachyos/docker-makepkg && docker rm dockerbuilder

It took about 30 mins, but it compiled and was able to install the .zst package once it was done without any issue.

On my system with AMD this package is building OK. On nvidia system I`m getting this error, but I really need nvidia support for proton :(

Uninstall cuda from your system and rebuild, or build in a clean chroot, or use paru which can be configured to build packages in a clean chroot.

I posted to the upstream github repo here: https://github.com/CachyOS/proton-cachyos/issues/6

The developer of CachyOS replied with:

Can you reproduce this issue in a chroot? e.g docker-makepkg or pkgctl builld ?

As someone who's not a developer and not as well versed in these things (tho general linux admin I'm pretty good at) I asked for more info on what this means. I suspect that during the compilation process it needs root in order to "see" the library in /opt/cuda/include/cub - my suspicion is based on the suggestion to use docker-makepkg which somehow "spoofs" root and "allows" the rest of the compilation process to complete, but this feels like an overwrought solution that I also do not know how to implement. Anyone else may have an idea on how to proceed here?