120 | std::variant<const TIntermConstantUnion*, const TType*> value; | ^~~~~~~ /usr/include/glslang/Include/SpirvIntrinsics.h:120:5: note: std::variant is only available from C++17 onwards 120 | std::variant<const TIntermConstantUnion*, const TType*> value; | ^~~ /usr/include/glslang/Include/SpirvIntrinsics.h: In constructor glslang::TSpirvTypeParameter::TSpirvTypeParameter(const glslang::TIntermConstantUnion*): /usr/include/glslang/Include/SpirvIntrinsics.h:100:60: error: value was not declared in this scope 100 | TSpirvTypeParameter(const TIntermConstantUnion* arg) { value = arg; } | ^~~~~ ------------------------------------------------------------------- This is an unstable amd64 chroot image at a tinderbox (==build bot) name: 23.0_systemd-20231028-165512 ------------------------------------------------------------------- gcc-config -l: [1] x86_64-pc-linux-gnu-10 [2] x86_64-pc-linux-gnu-13 * clang/llvm (if any): /usr/lib/llvm/17 17.0.4 Python 3.11.6 Available Ruby profiles: [1] ruby31 (with Rubygems) * Available Rust versions: [1] rust-bin-1.73.0 [2] rust-1.73.0 * The following VMs are available for generation-2: 1) Eclipse Temurin JDK 11.0.20.1_p1 [openjdk-bin-11] 2) Eclipse Temurin JDK 17.0.8.1_p1 [openjdk-bin-17] 3) Eclipse Temurin JDK 21.0.1_p12 [openjdk-bin-21] *) Eclipse Temurin JDK 8.382_p05 [openjdk-bin-8] Available Java Virtual Machines: [1] openjdk-bin-8 system-vm [2] openjdk-bin-11 [3] openjdk-bin-17 [4] openjdk-bin-21 The Glorious Glasgow Haskell Compilation System, version 9.2.8 php cli (if any): go version go1.21.4 linux/amd64 HEAD of ::gentoo commit 4da82315fb6d5aa99cd19b6c0f4bf2a90f526bae Author: Repository mirror & CI <repomirrorci@gentoo.org> Date: Sat Nov 11 04:46:54 2023 +0000 2023-11-11 04:46:53 UTC emerge -qpvO media-gfx/renderdoc [ebuild R ] media-gfx/renderdoc-1.29 USE="-doc -pyside2 -qt5 -verify-sig" PYTHON_SINGLE_TARGET="python3_11 -python3_10"
Created attachment 874548 [details] emerge-info.txt
Created attachment 874549 [details] emerge-history.txt.xz
Created attachment 874550 [details] environment
Created attachment 874551 [details] etc.portage.tar.xz
Created attachment 874552 [details] media-gfx:renderdoc-1.29:20231111-065533.log
Created attachment 874553 [details] qlist-info.txt.xz
Created attachment 874554 [details] temp.tar.xz
Incompatible with glslang change. Will try and fix, but in the meantime will block >=dev-util/glslang-1.3.268-r2 in renderdoc depend.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=04335ecc47da8979e94ff01f74de3099bcc57367 commit 04335ecc47da8979e94ff01f74de3099bcc57367 Author: Matthew Smith <matthew@gentoo.org> AuthorDate: 2023-11-12 07:50:34 +0000 Commit: Matthew Smith <matthew@gentoo.org> CommitDate: 2023-11-12 07:51:58 +0000 media-gfx/renderdoc: incompatibility with glslang-1.3.268 Bug: https://bugs.gentoo.org/917163 Signed-off-by: Matthew Smith <matthew@gentoo.org> media-gfx/renderdoc/{renderdoc-1.27.ebuild => renderdoc-1.27-r1.ebuild} | 2 +- media-gfx/renderdoc/{renderdoc-1.28.ebuild => renderdoc-1.28-r1.ebuild} | 2 +- media-gfx/renderdoc/{renderdoc-1.29.ebuild => renderdoc-1.29-r1.ebuild} | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-)
What's the initial reason behind depending on system glslang as opposed to vendored one? I've been unable to find it in history/blame, it seems to have been there from the very beginning w/o any rationale. I've tried building a patched ebuild locally, disabling system-glslang and system-compress patches. It seems to build and work just fine, although I haven't tested it extensively. What I propose is to either completely remove the dependency on system glslang and compress, or make it optional under a USE flag.
Created attachment 875873 [details, diff] patch cmake to use -std=c++17 instead of -std=c++11 seems like dev-util/glslang-1.3.268-r2 now requires c++ 17, by using std::variant on it's headers renderdoc is using -std=c++11, the patch makes cmake use -std=c++17 and it seems to be building and running fine under 17
Sorry for the delay. (In reply to provod from comment #10) > What's the initial reason behind depending on system glslang as opposed to > vendored one? I've been unable to find it in history/blame, it seems to have > been there from the very beginning w/o any rationale. I think in the long run, unbundling libraries is better for compatibility. https://wiki.gentoo.org/wiki/Why_not_bundle_dependencies It hasn't really had any issues up until now. If it keeps breaking in the future we can just use the vendored copy. (In reply to Anna from comment #11) > seems like dev-util/glslang-1.3.268-r2 now requires c++ 17 Thanks!
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=5dd18e883c89eaec43c3576c30ff1f7df0aebbbd commit 5dd18e883c89eaec43c3576c30ff1f7df0aebbbd Author: Matthew Smith <matthew@gentoo.org> AuthorDate: 2023-12-03 13:15:27 +0000 Commit: Matthew Smith <matthew@gentoo.org> CommitDate: 2023-12-03 13:17:06 +0000 media-gfx/renderdoc: fix compat w/ glslang-1.3.268-r2 Closes: https://bugs.gentoo.org/917163 Suggested-by: Anna <navi@vlhl.dev> Signed-off-by: Matthew Smith <matthew@gentoo.org> .../files/renderdoc-1.29-r2-system-compress.patch | 144 +++++++++++ .../files/renderdoc-1.29-r2-system-glslang.patch | 268 +++++++++++++++++++++ media-gfx/renderdoc/renderdoc-1.29-r2.ebuild | 202 ++++++++++++++++ 3 files changed, 614 insertions(+)
