[GH-ISSUE #3840] [APP BUG]: Builds now failing on Linux

kerem commented

2026-02-27 21:10:13 +03:00

Owner

Originally created by @Shoegzer on GitHub (Nov 29, 2025).
Original GitHub issue: https://github.com/shadps4-emu/shadPS4/issues/3840

Checklist

I have searched for a similar issue in this repository and did not find one.
I am using an official build obtained from releases or updated one of those builds using its in-app updater.

Describe the Bug

Builds are failing on linux.

Bad build: 78e301c3db
Last known good build: f557c6ac64

Can bisect if necessary.

Build log is here: build.log

Reproduction Steps

cmake -S . -B build/ -DENABLE_QT_GUI=ON -DCMAKE_C_COMPILER=clang -DCMAKE_CXX_COMPILER=clang++

Expected Behavior

Build succeeds

Specify OS Version

Linux Mint 22.2 / kernel 6.14

CPU

Intel Core i9-14900HX

GPU

Nvidia GTX 4070

Amount of RAM in GB

64 GB

Originally created by @Shoegzer on GitHub (Nov 29, 2025). Original GitHub issue: https://github.com/shadps4-emu/shadPS4/issues/3840 ### Checklist - [x] I have searched for a similar issue in this repository and did not find one. - [x] I am using an official build obtained from [releases](https://github.com/shadps4-emu/shadPS4/releases) or updated one of those builds using its in-app updater. ### Describe the Bug Builds are failing on linux. Bad build: 78e301c3db87cf517a4bde5542e397ff803859ce Last known good build: f557c6ac645337feb898b8174aff7a7e6f03c03e Can bisect if necessary. Build log is here: [build.log](https://github.com/user-attachments/files/23836509/build.log) ### Reproduction Steps `cmake -S . -B build/ -DENABLE_QT_GUI=ON -DCMAKE_C_COMPILER=clang -DCMAKE_CXX_COMPILER=clang++` ### Expected Behavior Build succeeds ### Specify OS Version Linux Mint 22.2 / kernel 6.14 ### CPU Intel Core i9-14900HX ### GPU Nvidia GTX 4070 ### Amount of RAM in GB 64 GB

kerem commented

2026-02-27 21:10:14 +03:00

Author

Owner

@Shoegzer commented on GitHub (Nov 30, 2025):

Update: Since the above test involved clang-21, re-tested build against clang-18 since this is recommended, however it still fails at a different point:

(.text+0x37d1): undefined reference to `spvOpcodeIsBlockTerminator(spv::Op)'
clang++-18: error: linker command failed with exit code 1 (use -v to see invocation)
gmake[2]: *** [CMakeFiles/shadps4.dir/build.make:5215: shadps4] Error 1
gmake[1]: *** [CMakeFiles/Makefile2:579: CMakeFiles/shadps4.dir/all] Error 2
gmake: *** [Makefile:136: all] Error 2

build.log

Note that building also fails with gcc (gcc-14.2.0)

@Shoegzer commented on GitHub (Nov 30, 2025): Update: Since the above test involved clang-21, re-tested build against clang-18 since this is recommended, however it still fails at a different point: ``` (.text+0x37d1): undefined reference to `spvOpcodeIsBlockTerminator(spv::Op)' clang++-18: error: linker command failed with exit code 1 (use -v to see invocation) gmake[2]: *** [CMakeFiles/shadps4.dir/build.make:5215: shadps4] Error 1 gmake[1]: *** [CMakeFiles/Makefile2:579: CMakeFiles/shadps4.dir/all] Error 2 gmake: *** [Makefile:136: all] Error 2 ``` [build.log](https://github.com/user-attachments/files/23840814/build.log) Note that building also fails with gcc (gcc-14.2.0)

kerem commented

2026-02-27 21:10:14 +03:00

Author

Owner

@Shoegzer commented on GitHub (Dec 8, 2025):

Update: Linux builds continue to fail as of commit 65f0b07c34. Also, given the following in cmake, could linux builds be failing due to an incompatibility with more recent vulkan apis? The building section does not specify a required version.

CMake Warning at CMakeLists.txt:238 (find_package):
  Could not find a configuration file for package "VulkanHeaders" that is
  compatible with requested version "1.4.329".

  The following configuration files were considered but not accepted:

    /home/testing/.local/lib/vulkan/1.4.328.1/x86_64/share/cmake/VulkanHeaders/VulkanHeadersConfig.cmake, version: 1.4.328

@Shoegzer commented on GitHub (Dec 8, 2025): Update: Linux builds continue to fail as of commit 65f0b07c34d0d0fe43bbcb25556741bb629b233e. Also, given the following in cmake, could linux builds be failing due to an incompatibility with more recent vulkan apis? The [building](https://github.com/shadps4-emu/shadPS4/blob/main/documents/building-linux.md) section does not specify a required version. ``` CMake Warning at CMakeLists.txt:238 (find_package): Could not find a configuration file for package "VulkanHeaders" that is compatible with requested version "1.4.329". The following configuration files were considered but not accepted: /home/testing/.local/lib/vulkan/1.4.328.1/x86_64/share/cmake/VulkanHeaders/VulkanHeadersConfig.cmake, version: 1.4.328 ```

kerem commented

2026-02-27 21:10:14 +03:00

Author

Owner

@Shoegzer commented on GitHub (Dec 13, 2025):

Updated: Tested against #3865 which resolves certain issues with linux builds, though it didn't fix the issue here unfortunately. Test system added the mold package as it was missing and the above submission installs it, though to no effect.

@georgemoralis Any ideas what could be happening on linux?

@Shoegzer commented on GitHub (Dec 13, 2025): Updated: Tested against #3865 which resolves certain issues with linux builds, though it didn't fix the issue here unfortunately. Test system added the `mold` package as it was missing and the above submission installs it, though to no effect. @georgemoralis Any ideas what could be happening on linux?

kerem commented

2026-02-27 21:10:14 +03:00

Author

Owner

@georgemoralis commented on GitHub (Dec 13, 2025):

latest sdl3 required ibxcursor-dev libxi-dev libxss-dev libxtst-dev for ci to build. Maybe you are missing some of these packages?

@georgemoralis commented on GitHub (Dec 13, 2025): latest sdl3 required ibxcursor-dev libxi-dev libxss-dev libxtst-dev for ci to build. Maybe you are missing some of these packages?

kerem commented

2026-02-27 21:10:14 +03:00

Author

Owner

@Shoegzer commented on GitHub (Dec 13, 2025):

Thanks, good thought but those are all installed on the system. The dependencies listed in the build docs are all installed as well, though perhaps there's something else with the build environment?

Other info:

$ grep VULKAN_SDK ~/.profile 
export VULKAN_SDK=~/.local/lib/vulkan/1.4.335.0/x86_64
export PATH=$VULKAN_SDK/bin:$PATH
export LD_LIBRARY_PATH=$VULKAN_SDK/lib${LD_LIBRARY_PATH:+:$LD_LIBRARY_PATH}
export VK_ADD_LAYER_PATH=$VULKAN_SDK/share/vulkan/explicit_layer.d

$ pkgconf --modversion sdl3
3.2.28

$ qmake --version
QMake version 3.1
Using Qt version 6.9.3 in /usr/local/Qt-6.9.3/lib

$ cmake --version
cmake version 3.28.3

$ clang --version
Ubuntu clang version 21.1.8 (++20251212093602+51e5074676d4-1~exp1~20251212093735.68)

$ llvm-config --version
18.1.3

$ gcc --version
gcc (Ubuntu 14.2.0-4ubuntu2~24.04) 14.2.0

@Shoegzer commented on GitHub (Dec 13, 2025): Thanks, good thought but those are all installed on the system. The dependencies listed in the [build](https://github.com/shadps4-emu/shadPS4/blob/main/documents/building-linux.md) docs are all installed as well, though perhaps there's something else with the build environment? Other info: ``` $ grep VULKAN_SDK ~/.profile export VULKAN_SDK=~/.local/lib/vulkan/1.4.335.0/x86_64 export PATH=$VULKAN_SDK/bin:$PATH export LD_LIBRARY_PATH=$VULKAN_SDK/lib${LD_LIBRARY_PATH:+:$LD_LIBRARY_PATH} export VK_ADD_LAYER_PATH=$VULKAN_SDK/share/vulkan/explicit_layer.d ``` ``` $ pkgconf --modversion sdl3 3.2.28 ``` ``` $ qmake --version QMake version 3.1 Using Qt version 6.9.3 in /usr/local/Qt-6.9.3/lib ``` ``` $ cmake --version cmake version 3.28.3 ``` ``` $ clang --version Ubuntu clang version 21.1.8 (++20251212093602+51e5074676d4-1~exp1~20251212093735.68) ``` ``` $ llvm-config --version 18.1.3 ``` ``` $ gcc --version gcc (Ubuntu 14.2.0-4ubuntu2~24.04) 14.2.0 ```

kerem commented

2026-02-27 21:10:14 +03:00

Author

Owner

@Shoegzer commented on GitHub (Dec 19, 2025):

I'm assuming my environment above meets (and doesn't exceed) all the minimum requirements for building.

I should add that even when shadps4 was building on linux systems, per #1195, it has required manually correcting the path to visibility.h in the following files:

externals/glslang/SPIRV/GlslangToSpv.h
externals/glslang/SPIRV/Logger.h

This seems to be a yet-unresolved issue with external glslang, but in any event, I wonder if the new problem above is due to similar issues with incorrect paths to header files.

@qurious-pixel I assume you're unable to build too? And if not, have you found a workaround for it?

@Shoegzer commented on GitHub (Dec 19, 2025): I'm assuming my environment above meets (and doesn't exceed) all the minimum requirements for building. I should add that even when shadps4 was building on linux systems, per #1195, it has required manually correcting the path to` visibility.h` in the following files: `externals/glslang/SPIRV/GlslangToSpv.h` `externals/glslang/SPIRV/Logger.h` This seems to be a yet-unresolved issue with external glslang, but in any event, I wonder if the new problem above is due to similar issues with incorrect paths to header files. @qurious-pixel I assume you're unable to build too? And if not, have you found a workaround for it?

kerem commented

2026-02-27 21:10:14 +03:00

Author

Owner

@dkman123 commented on GitHub (Dec 25, 2025):

You may be able to compile if you change the line in CMakeLists.txt

-find_package(VulkanHeaders 1.4.329 CONFIG)
+find_package(VulkanHeaders 1.4.328 CONFIG)

I also had to change

-find_package(glslang 15 CONFIG)
+find_package(glslang 16 CONFIG)

I'm not saying that it will work afterward, but it might compile.

Edit: In case you don't know how to read that, it's taking out the line starting with minus and adding the line starting with plus. Though in this case you only need to change the one character/digit.

@dkman123 commented on GitHub (Dec 25, 2025): You may be able to compile if you change the line in CMakeLists.txt -find_package(VulkanHeaders 1.4.329 CONFIG) +find_package(VulkanHeaders 1.4.328 CONFIG) I also had to change -find_package(glslang 15 CONFIG) +find_package(glslang 16 CONFIG) I'm not saying that it will work afterward, but it might compile. Edit: In case you don't know how to read that, it's taking out the line starting with minus and adding the line starting with plus. Though in this case you only need to change the one character/digit.

kerem commented

2026-02-27 21:10:14 +03:00

Author

Owner

@Shoegzer commented on GitHub (Dec 28, 2025):

Thanks, that's helpful although building still fails after those changes. Here's the log:

build.log

A few questions:

I assume you were getting the exact same error before you fixed it? Also, why did those changes actually fix this for you? Maybe I can work backwards from there.
What OS and environment are you working with, any differences from this one? Given that shadps4 no longer builds on certain linux environments, it would be good to know the specific conditions so a proper fix can be committed.
How did you setup vulkan sdk? Over here it was downloaded from sdk.lunarg.com to ~/.local/lib/vulkan, then the VULKAN_SDK environment was established in ~/.profile as per the post above. There is a ~/.local/lib/vulkan//1.4.328.1/vulkansdk binary but that was not used at all.

@Shoegzer commented on GitHub (Dec 28, 2025): Thanks, that's helpful although building still fails after those changes. Here's the log: [build.log](https://github.com/user-attachments/files/24357224/build.log) A few questions: 1. I assume you were getting the exact same error before you fixed it? Also, why did those changes actually fix this for you? Maybe I can work backwards from there. 2. What OS and environment are you working with, any differences from this one? Given that shadps4 no longer builds on certain linux environments, it would be good to know the specific conditions so a proper fix can be committed. 3. How did you setup vulkan sdk? Over here it was downloaded from sdk.lunarg.com to `~/.local/lib/vulkan`, then the VULKAN_SDK environment was established in `~/.profile` as per the post above. There is a `~/.local/lib/vulkan//1.4.328.1/vulkansdk` binary but that was not used at all.

kerem commented

2026-02-27 21:10:14 +03:00

Author

Owner

@mittonk commented on GitHub (Jan 9, 2026):

From a similar setup: Using libstdc++-13 rather than the 14 in that error worked around std::jthread arguments must be invocable after conversion to rvalues . I haven't poked that enough to understand what changed, or if something needs to be adjusted for libstdc++-14.

$ cmake -DCMAKE_CXX_FLAGS="--gcc-install-dir=/usr/lib/gcc/x86_64-linux-gnu/13" ...

Also had problems with CMake picking up a similarly-versioned glslang from elsewhere (cmake --debug-find ... showed that explicitly) --- forcing use of the copy in externals/glslang solved that without changing import paths or version dependencies, used -DCMAKE_DISABLE_FIND_PACKAGE_glslang=ON .

So this worked around also-having-libstdc++-14 and also-having-other-glslang :

$ cmake -S . -B build/ -DCMAKE_DISABLE_FIND_PACKAGE_glslang=ON -DCMAKE_C_COMPILER=clang -DCMAKE_CXX_COMPILER=clang++ -DCMAKE_CXX_FLAGS="--gcc-install-dir=/usr/lib/gcc/x86_64-linux-gnu/13

@mittonk commented on GitHub (Jan 9, 2026): From a similar setup: Using libstdc++-13 rather than the 14 in that error worked around `std::jthread arguments must be invocable after conversion to rvalues `. I haven't poked that enough to understand what changed, or if something needs to be adjusted for libstdc++-14. ``` $ cmake -DCMAKE_CXX_FLAGS="--gcc-install-dir=/usr/lib/gcc/x86_64-linux-gnu/13" ... ``` Also had problems with CMake picking up a similarly-versioned glslang from elsewhere (`cmake --debug-find ...` showed that explicitly) --- forcing use of the copy in `externals/glslang` solved that without changing import paths or version dependencies, used `-DCMAKE_DISABLE_FIND_PACKAGE_glslang=ON `. So this worked around also-having-libstdc++-14 and also-having-other-glslang : ``` $ cmake -S . -B build/ -DCMAKE_DISABLE_FIND_PACKAGE_glslang=ON -DCMAKE_C_COMPILER=clang -DCMAKE_CXX_COMPILER=clang++ -DCMAKE_CXX_FLAGS="--gcc-install-dir=/usr/lib/gcc/x86_64-linux-gnu/13 ```

kerem commented

2026-02-27 21:10:14 +03:00

Author

Owner

@Shoegzer commented on GitHub (Jan 12, 2026):

From a similar setup: Using libstdc++-13 rather than the 14 in that error worked around std::jthread arguments must be invocable after conversion to rvalues . I haven't poked that enough to understand what changed, or if something needs to be adjusted for libstdc++-14.

Thanks! This is one of two reasons builds are failing, though indeed your workaround using -DCMAKE_CXX_FLAGS"--gcc-install-dir=/usr/lib/gcc/x86_64-linux-gnu/13 works assuming gcc-13 is installed. Hopefully the shadps4 dev team can look into supporting libstdc++14 with clang, as it would appear that anyone with gcc-14/libstdc++-14 will fail to build. If that happens I'll close this.

Also had problems with CMake picking up a similarly-versioned glslang from elsewhere.

Exactly. This is the second reason builds are failing, though thankfully fixable without any code changes. For background: recently the Vulkan team switched distributing the Vulkan SDK from their lunarg repo to a tarball, as described here. If you install the new tarball-based SDK without also removing remnants of the older repo-based SDK, conflicts such as this can result. In my case, an apt purge glslang-dev removed the conflict so that -DCMAKE_DISABLE_FIND_PACKAGE_glslang=ON is not necessary - though your workaround certainly works.

Incidentally, as an added bonus - the relative path fix I described in #1195 should no longer be necessary once the older repo-based glslang is purged.

@Shoegzer commented on GitHub (Jan 12, 2026): > From a similar setup: Using libstdc++-13 rather than the 14 in that error worked around std::jthread arguments must be invocable after conversion to rvalues . I haven't poked that enough to understand what changed, or if something needs to be adjusted for libstdc++-14. Thanks! This is one of two reasons builds are failing, though indeed your workaround using `-DCMAKE_CXX_FLAGS"--gcc-install-dir=/usr/lib/gcc/x86_64-linux-gnu/13` works assuming gcc-13 is installed. Hopefully the shadps4 dev team can look into supporting libstdc++14 with clang, as it would appear that anyone with gcc-14/libstdc++-14 will fail to build. If that happens I'll close this. > Also had problems with CMake picking up a similarly-versioned glslang from elsewhere. Exactly. This is the second reason builds are failing, though thankfully fixable without any code changes. For background: recently the Vulkan team switched distributing the Vulkan SDK from their lunarg repo to a tarball, as described [here](https://docs.vulkan.org/tutorial/latest/02_Development_environment.html#_linux_2). If you install the new tarball-based SDK without also removing remnants of the older repo-based SDK, conflicts such as this can result. In my case, an `apt purge glslang-dev` removed the conflict so that `-DCMAKE_DISABLE_FIND_PACKAGE_glslang=ON` is not necessary - though your workaround certainly works. Incidentally, as an added bonus - the relative path fix I described in #1195 should no longer be necessary once the older repo-based glslang is purged.

kerem referenced this issue

2026-02-27 21:14:36 +03:00

[PR #1150] [MERGED] Fix fmt error #1956

Rows
Columns

[GH-ISSUE #3840] [APP BUG]: Builds now failing on Linux #1150

Checklist

Describe the Bug

Reproduction Steps

Expected Behavior

Specify OS Version

CPU

GPU

Amount of RAM in GB