VulkanSceneGraph icon indicating copy to clipboard operation
VulkanSceneGraph copied to clipboard

glslang min_request_version does not accept 15.0.0

Open psi29a opened this issue 1 year ago • 16 comments

Describe the bug Looks like cmake is not parsing 15.0.0 correctly and claims that it does not meet the min requirement of 14.

To Reproduce Steps to reproduce the behavior:

Debian Sid

https://packages.debian.org/source/sid/glslang

cmake .

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

  The following configuration files were considered but not accepted:

    /usr/lib/x86_64-linux-gnu/cmake/glslang/glslang-config.cmake, version: 15.0.0
    /lib/x86_64-linux-gnu/cmake/glslang/glslang-config.cmake, version: 15.0.0



CMake Warning at CMakeLists.txt:52 (message):
  glslang not found.  ShaderCompile support disabled.

Expected behavior Should configure and find glslang

Screenshots If applicable, add screenshots to help explain your problem.

Desktop (please complete the following information):

  • OS: Debian Sid
  • Version 1.1.7

Additional context I'm packaging VSG upstream to Debian

psi29a avatar Nov 10 '24 16:11 psi29a

Change the value to "14.0.0" does not resolve the issue either.

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

  The following configuration files were considered but not accepted:

    /usr/lib/x86_64-linux-gnu/cmake/glslang/glslang-config.cmake, version: 15.0.0
    /lib/x86_64-linux-gnu/cmake/glslang/glslang-config.cmake, version: 15.0.0

psi29a avatar Nov 10 '24 16:11 psi29a

Could the glslang-config be buggy and not accepting support for older versions? Or is 15 not officially compatible with 14?

I wonder if removing the version check in the find_package line and then checking the version if it's found might work.

robertosfield avatar Nov 10 '24 17:11 robertosfield

As we discussed last time this came up, glslang's generated CMake config (specifically glslang-config-version.cmake) is set up to deny backwards compatibility if there's a major version change. There are options that let us specify a maximum version, too, but they're ignored if the major version differs for the minimum and maximum we set, so they won't save us here.

I don't think they set things up like that intentionally, it's just how CMake defaults to doing things, and they seem to expect that most projects using glslang use a Windows-style workflow where you clone and build the specific version of all dependencies that you want, instead of the Linux-style workflow, letting the system package manager provide your dependencies and having to deal with whichever versions it decides to give you. If we report it to them, it'll probably sit around unsolved like most of their CMake problems, but they'd probably accept a well-reasoned PR. I think I looked into it and decided it wasn't trivial, so would require at least a little bit of thought, so put it off for another day.

In the meantime, just set GLSLANG_MIN_VERSION to 15 by setting -DGLSLANG_MIN_VERSION=15 on the command line during configure, and everything should be fine.

AnyOldName3 avatar Nov 10 '24 18:11 AnyOldName3

Alrighty, we resolved it and package is here: https://mentors.debian.net/package/vulkanscenegraph/ Awaiting lawyer review from FTPMasters and uploading.

Once there, I'll package up the rest: vsgXchange and examples.

Feel free to close this.

psi29a avatar Nov 11 '24 10:11 psi29a

What was the solution? To use Chris' suggestion?

It'd be good to have a general solution of the box so won't close it for now.

robertosfield avatar Nov 11 '24 10:11 robertosfield

For the Debian package we just patched the GLSLANG_MIN_VERSION to 15 from 14. It's less work for us to carry this patch and drop when no longer necessary. We want to keep our d/rules clean, so no need to set a define.

https://salsa.debian.org/games-team/vulkanscenegraph/-/blob/master/debian/patches/001-glslang-min-version.patch?ref_type=heads

psi29a avatar Nov 11 '24 11:11 psi29a

I just ran into this using VSG from vcpkg. There the workaround is to create an overlay that passes -DGLSLANG_MIN_VERSION=15 to vcpkg_cmake_configure. The proper thing to do is to submit a PR to vcpkg that includes this change. Does anyone claim ownership over the vsg port in vcpkg? I see that @gwaldron submittted that last PR there; Glenn, do you want to make this change, or should I go ahead and do it?

timoore avatar Nov 21 '24 13:11 timoore

@timoore I will look into this today - thanks.

[update] @timoore I grabbed the latest vcpkg and rebuilt vsg, vsgXchange, and vsgQt via Rocky. glslang version = 15.0.0. It built OK, but I got this runtime error:

[vsg critical] VulkanSceneGraph not compiled with GLSLang, unable to compile shaders.

Adding -DGLSLANG_MIN_VERSION=15 to the portfile fixes the problem, confirmed.

So I will submit that PR to vcpkg to support 1.1.7, and @robertosfield can make the call whether to burn this into VSG proper for the next tagged release. https://github.com/microsoft/vcpkg/pull/42294

Hope that works :)

gwaldron avatar Nov 21 '24 14:11 gwaldron

I have done some experiments on my Kubuntu 24.04 system that has either glslang-dev package installed that has glslang 14.x or glslang built from source that is 15.x.

Without any changes I saw the same cmake error as others have reported. To workaround this issue I have refactor the glslang find code so that it first tries 15, and if that fails fallbacks to trying 14. The change is now checked into VSG master: e07a9a753facd12f30fe2a782ee51ddc2cf264d1

I will be tagging a VSG dev release later today/tomorrow that will include this. Would appreciate others have a look over it and ideally test it as well. Thanks.

robertosfield avatar Dec 12 '24 11:12 robertosfield

We're probably going to have the same issue with glslang 16 when it appears (unless we convince the upstream maintainers to customise their glslang-config-version.cmake so it accepts a version range that spans multiple major versions before it's branched), so it might be sensible to use a loop instead of having two explicit find_package calls.

AnyOldName3 avatar Dec 12 '24 15:12 AnyOldName3

FWIW, the vcpkg team would only accept a patch that passed in -DGLSLANG_MIN_VERSION= which disables the explicit check and works with both 14 and 15 (and presumably 15+ in the future, which drove their reasoning).

gwaldron avatar Dec 12 '24 16:12 gwaldron

The original problem was that we knew 13.x and older definitely didn't work properly on Windows as glslang's CMake was a mess. vcpkg's glslang port had workarounds for many of the problems, so older versions from there were mostly fine anyway, so the minimum version check is less important there.

The original intention was that the check would permit 14+, and it was only when 15 was released that we realised it meant $[14,15)$ as major versions had to match, even when the upper bound is explicit.

AnyOldName3 avatar Dec 12 '24 16:12 AnyOldName3

I have been wondering about simply dropping the version check on the find_package and trying to come up with an alternative version check in the CMake.

We used to have a bit of convoluted systems for detecting glslang version but that got removed when I moved glslang to be internal.

robertosfield avatar Dec 13 '24 09:12 robertosfield

The main reason I can think of not to do that is that having it in the find_package call means that it'll skip older versions that it finds first. It's pretty common to have multiple glslang builds installed side-by-side as the Vulkan SDK provides one, and it'd be a pain if someone's Vulkan SDK wasn't up to date, so provided an older glslang build, and the VSG insisted on trying to use it even though it was too old and a newer one was also installed. On the other hand, this problem can be avoided by changing the order things are listed in CMAKE_PREFIX_PATH etc. so the desired build is found first.

AnyOldName3 avatar Dec 13 '24 14:12 AnyOldName3

glslangValidator --version

returns

Glslang Version: 11:15.1.0

This results in a CMake error message: CMake Warning at CMakeLists.txt:54 (find_package): Could not find a configuration file for package "glslang" that is compatible with requested version "14".

The "11" prefix messes up the automatic version number recognition by CMake.

Dropping the version seems to resolve the issue

ifcapps avatar Jan 25 '25 15:01 ifcapps

The current CMake tries to find glslang 15 before it tries 14, so you'd only see that if you were using an older version or for whatever reason your 15.1 install wasn't visible to CMake (e.g. you don't have the development package, just the command-line tools).

AnyOldName3 avatar Jan 25 '25 15:01 AnyOldName3

@robertosfield It seems that this issue still persists. I have installed glslang version 16, yet CMake throws an error during compilation. For now, I will remove the version constraint to proceed with the compilation on my end.

OS: Ubuntu 20.04.2 LTS CMake version: 4.2.0

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

The following configuration files were considered but not accepted:

/usr/local/lib/cmake/glslang/glslang-config.cmake, version: 16.0.0
  The version found is not compatible with the version requested.

CMake Warning at CMakeLists.txt:60 (message): glslang not found. ShaderCompile support disabled.

KAlO2 avatar Dec 23 '25 03:12 KAlO2

I have installed built and installed glslang-16.1 from source and the find_package(glslang..) doesn't be default pick up on the 16.x version without changing the GLSLANG_MIN_VERSION from the default of 15 to 16.

I have decided that the easiest way to resolve this is to remove the version check entirely and this picks up on 14.x, 15.x and 16.x just fine for me under Kubuntu 22.04. I have also tested under Windows 11 and it works fine for me. Changes are merged with PR #1636. Could you checkout VSG master and let me know how you get on.

robertosfield avatar Dec 23 '25 12:12 robertosfield

Thank you, this would alleviate issues on my side of maintaining patches. Thanks!

psi29a avatar Dec 24 '25 11:12 psi29a