Latest Vulkan Validation Layers main gives weird undefined symbol error

[Joshua-Ashton]

Environment:

• OS: Arch Linux
• GPU and driver version: NVIDIA GeForce RTX 2060 Super && 550.76
• SDK or header version if building from repo: d84c3a5
• Options enabled (synchronization, best practices, etc.): Just enabling validation

Describe the Issue

I am not able to start with the latest Vulkan Validation Layers from git, as I get the following error:

Sat Apr 20 2024 09:31:30.056616 [Info] - vrlink: VRLINK_VK DEBUG: /usr/lib/libVkLayer_khronos_validation.so: undefined symbol: _ZN3vku42safe_VkVideoSessionParametersCreateInfoKHR10initializeEPK37VkVideoSessionParametersCreateInfoKHRPNS_14PNextCopyStateE

Expected behavior

I expect to not get a weird undefined symbol error.

Running ldd -d /usr/lib/libVkLayer_khronos_validation.so I actually see a whole bunch of undefined symbols.

Output of ldd -d /usr/lib/libVkLayer_khronos_validation.so

[spencer-lunarg]

Thanks @Joshua-Ashton for raising this, by chance did you use any special cmake arguments or just to "standard" build flow. Also which compiler are you using?

[Joshua-Ashton]

I'm using the args from the PKGBUILD, but it doesn't seem like there is much interesting there that would be related:

https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=vulkan-validation-layers-git

gcc/g++:

➜  ~ gcc --version
gcc (GCC) 13.2.1 20230801
Copyright (C) 2023 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

[spencer-lunarg]

Aww, so PNextCopyState is from the old Safe Struct utils that was moved over to

https://github.com/KhronosGroup/Vulkan-Utility-Libraries/

You will need to update your dependencies

[Joshua-Ashton]

Shouldn't the CMake check for all of this and guard against it? Typically you specify a minimum version of X or whatever.

[Joshua-Ashton]

I wonder if it may be actually my package only installing the Validation.so and the Vulkan-ValidationLayers project is building it's own utility thing that isn't what's actually on my system? I should look into that and report a packaging issue if so

[spencer-lunarg]

(cc @jeremyg-lunarg) (cc @juan-kitware if you are willing)

It should guard against this, -DUPDATE_DEPS=ON I thought detects a change and grabs the latest version

[Joshua-Ashton]

I don't think my package for the validation-layers-git would install that if so, it'd have to come from the utility-libraries-git pkg -- perhaps it should be statically linked if UPDATE_DEPS and otherwise check the version?

[spencer-lunarg]

so just to note, the big difference is the VUL repo was header only until 3 weeks ago (#7717 / KhronosGroup/Vulkan-Utility-Libraries#187) ... it now has a static lib it needs to pull in

[sharkautarch]

@Joshua-Ashton
Maybe the aur pkgbuild (referring to the build script itself) is older than the repo one
Perhaps just try taking the repo pkgbuild, and replacing the url in the source= with the github url thingy
repo pkgbuild here: https://gitlab.archlinux.org/archlinux/packaging/packages/vulkan-validation-layers/-/blob/main/PKGBUILD?ref_type=heads

[sharkautarch]

@Joshua-Ashton
I tested out building a version of the archlinux repo VVL pkgbuild modified to build against latest git
gist of the pkgbuild I used here: https://gist.github.com/sharkautarch/2d6147f559e178417eff4650462147ff

I haven't actually installed and tried running it yet, but, when I ran:
ldd -d src/Vulkan-ValidationLayers/build/layers/libVkLayer_khronos_validation.so
I didn't see any undefined symbols

so maybe this could just be a problem with the AUR vulkan-validation-layers-git pkgbuild???

BTW, here's my compile options in /etc/makepkg.conf file, just in case that could be a factor:

#
CARCH="x86_64"
CHOST="x86_64-pc-linux-gnu"

#-- Compiler and Linker Flags
#CPPFLAGS=""
CFLAGS="-march=native -O2 -fpie -pipe -fno-plt -fexceptions \
        -Wp,-D_FORTIFY_SOURCE=2 -Wformat -Werror=format-security \
        -fstack-clash-protection -fcf-protection"
CXXFLAGS="$CFLAGS -Wp,-D_GLIBCXX_ASSERTIONS"
LDFLAGS="-fuse-linker-plugin -Wl,-O1,--sort-common,--as-needed,-z,now"
LTOFLAGS="-flto=20"
RUSTFLAGS="-C target-cpu=native"
#-- Make Flags: change this for DistCC/SMP systems
MAKEFLAGS="-j$(nproc)"
#-- Debugging flags
#DEBUG_CFLAGS="-g"
DEBUG_CXXFLAGS="$DEBUG_CFLAGS"

also my kernel and cpu:

CPU: 14-core (6-mt/8-st) 12th Gen Intel Core i7-12700H (-MST AMCP-)
speed/min/max: 496/400/4600:4700:3500 MHz Kernel: 6.8.1-arch1-1 x86_64

[juan-kitware]

It should guard against this, -DUPDATE_DEPS=ON I thought detects a change and grabs the latest version

Package mangers don't generally use UPDATE_DEPS=ON they package the dependencies on their own. Either for security / performance reasons.

Shouldn't the CMake check for all of this and guard against it? Typically you specify a minimum version of X or whatever.

Usually the REQUIRED keyword is enough. However, we were requested to remove it.

#6587
#6595