Arch Linux User Repository

@iamkroot it doesn't, since it builds fine on my CI in clean chroots. It might require git-lfs due to system conf which is otherwise not present in a clean chroot.

Needs git-lfs as a make dep

That rust error comes from ALHP repos, sorry.

     Running `rustc --crate-name syn --edition=2018 /ssd2/csaba/.cache/yay/proton-cachyos/proton-cargo/registry/src/index.crates.io-1949cf8c6b5b557f/syn-1.0.109/src/lib.rs --error-format=json --json=diagnostic-rendered-ansi,artifacts,future-incompat --diagnostic-width=202 --crate-type lib --emit=dep-info,metadata,link -C embed-bitcode=no -C debuginfo=2 -C debug-assertions=off --cfg 'feature="clone-impls"' --cfg 'feature="default"' --cfg 'feature="derive"' --cfg 'feature="full"' --cfg 'feature="parsing"' --cfg 'feature="printing"' --cfg 'feature="proc-macro"' --cfg 'feature="quote"' --check-cfg 'cfg(docsrs,test)' --check-cfg 'cfg(feature, values("clone-impls", "default", "derive", "extra-traits", "fold", "full", "parsing", "printing", "proc-macro", "quote", "test", "visit", "visit-mut"))' -C metadata=da40bc5b15f696d5 -C extra-filename=-59e75b43b920379c --out-dir /ssd2/csaba/.cache/yay/proton-cachyos/src/build/obj-gst_plugins_rs-i386/release/deps -L dependency=/ssd2/csaba/.cache/yay/proton-cachyos/src/build/obj-gst_plugins_rs-i386/release/deps --extern proc_macro2=/ssd2/csaba/.cache/yay/proton-cachyos/src/build/obj-gst_plugins_rs-i386/release/deps/libproc_macro2-00b391edf0dababd.rmeta --extern quote=/ssd2/csaba/.cache/yay/proton-cachyos/src/build/obj-gst_plugins_rs-i386/release/deps/libquote-358494dfa8c9c49b.rmeta --extern unicode_ident=/ssd2/csaba/.cache/yay/proton-cachyos/src/build/obj-gst_plugins_rs-i386/release/deps/libunicode_ident-1fc38e21d4a65e6a.rmeta --cap-lints allow --cfg syn_disable_nightly_tests`
error: linking with `cc` failed: exit status: 1
  |
  = note:  "cc" "-Wl,--version-script=/tmp/rustcnapRv3/list" "-Wl,--no-undefined-version" "-m64" "/tmp/rustcnapRv3/symbols.o" "<8 object files omitted>" "/tmp/rustcnapRv3/rmeta.o" "<1 object files omitted>" "-Wl,--as-needed" "-Wl,-Bstatic" "<sysroot>/lib/rustlib/x86_64-unknown-linux-gnu/lib/{libproc_macro-*,librustc_literal_escaper-*,librustc_std_workspace_std-*,libstd-*,libpanic_unwind-*,libobject-*,libmemchr-*,libaddr2line-*,libgimli-*,librustc_demangle-*,libstd_detect-*,libhashbrown-*,librustc_std_workspace_alloc-*,libminiz_oxide-*,libadler2-*,libunwind-*,libcfg_if-*,liblibc-*,librustc_std_workspace_core-*,liballoc-*,libcore-*,libcompiler_builtins-*}.rlib" "-Wl,-Bdynamic" "-lgcc_s" "-lutil" "-lrt" "-lpthread" "-lm" "-ldl" "-lc" "-L" "/tmp/rustcnapRv3/raw-dylibs" "-Wl,--eh-frame-hdr" "-Wl,-z,noexecstack" "-L" "<sysroot>/lib/rustlib/x86_64-unknown-linux-gnu/lib" "-o" "/ssd2/csaba/.cache/yay/proton-cachyos/src/build/obj-gst_plugins_rs-i386/release/deps/libpaste-c7f8cb1622f5e916.so" "-Wl,--gc-sections" "-shared" "-Wl,-z,relro,-z,now" "-nodefaultlibs"
  = note: some arguments are omitted. use `--verbose` to show all linker arguments
  = note: /usr/bin/ld: /usr/lib/rustlib/x86_64-unknown-linux-gnu/lib/libproc_macro-68e7be1c71cd87ea.rlib: error adding symbols: file format not recognized
          collect2: error: ld returned 1 exit status


error: could not compile `paste` (lib) due to 1 previous error

Caused by:
  process didn't exit successfully: `rustc --crate-name paste --edition=2018 /ssd2/csaba/.cache/yay/proton-cachyos/proton-cargo/registry/src/index.crates.io-1949cf8c6b5b557f/paste-1.0.15/src/lib.rs --error-format=json --json=diagnostic-rendered-ansi,artifacts,future-incompat --diagnostic-width=202 --crate-type proc-macro --emit=dep-info,link -C prefer-dynamic -C embed-bitcode=no -C debuginfo=2 -C debug-assertions=off

@QTaKs There is, although there are just too many submodules,and even the submodules have their own submodules. There are possibly 3 or 4 levels of nested submodules that should be taken care of.

The other reason I stopped using the source array is that it clones the submodule repositories in their entirety (they are mirrors after all), and that increases the storage usage, causing my GH workflow to fail. The PKGBUILD instead tries to clone as little as possible by filtering git submodule update --init --filter=tree:0 --recursive

Is there any possibility to download submodules via source list? This is to avoid redownloading and reusing already cloned ones.

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.