Failure to build Gtk4 because of missing vulkan headers
See original GitHub issueVulkan headers not found
After configuring, meson reports that vulkan dependency is satisfied:
Dependency vulkan found: YES 1.2.153 (cached)
but building by invoking ninja fails with this error:
In file included from ../gdk/gdkinternals.h:38,
from ../gdk/gdkdrop.c:32:
../gdk/gdkdisplayprivate.h:31:10: fatal error: vulkan/vulkan.h: No such file or directory
31 | #include <vulkan/vulkan.h>
| ^~~~~~~~~~~~~~~~~
compilation terminated.
the gtk4 meson.build file already include a test for vulkan
# Check for Vulkan support
# Uses meson's custom vulkan dependency searching. Set the VULKAN_SDK env var
# to use a custom path for the Vulkan SDK. Bugs that are found with it should
# be reported upstream and fixed.
vulkan_dep = dependency('vulkan', required: get_option('vulkan'))
I’m on Manjaro/Gnome 3.38/X11 system.
meson version: 0.56.0
ninja version: 1.10.1
Python 3.8.6
After installing vulkan-headers package the failure is resolved.
Issue Analytics
- State:
- Created 3 years ago
- Reactions:1
- Comments:5 (2 by maintainers)
Top Results From Across the Web
Test for Vulkan headers before building - gtk - GNOME Gitlab
I was trying to build gtk4 form git in a new machine, although every dependency was satisfied during meson configure, but build failed...
Read more >Bug #1742711 “MIR: vulkan-loader” : Bugs : vulkan-loader package ...
It is intended to demote qt to universe for 19.04. gtk4 is not expected to enter ... tests fail due to missing vulkan...
Read more >gtk4-git - AUR (en) - Arch Linux
Doesn't build for me: Program glib-compile-resources found: YES (/usr/bin/glib-compile-resources) Configuring org.gtk.gtk4.NodeEditor.appdata.xml using ...
Read more >Build and run GTK 4 applications with Visual Studio - Collabora
The best stress test is to build projects on Windows, without msys2 , because it has no dependencies or tools installed (e.g. pkg-config)....
Read more >GRUB error cannot find a GRUB drive, after a failed update
gtk-update-icon-cache-1:4.8.2-1 gtk4-1:4.8.2-1 harfbuzz-5.3.1-3 ... HTTPConnection object at 0x7f31bd0f07c0>: Failed to establish a new ...
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found

This dependency troubles and confuses me.
vulkan.pc, as distributed by the KhronosGroup, provides a dependency for the Vulkan Loader, not the Vulkan Headers. So the results you got are technically correct – the SDK cannot be called “vulkan” as it clashes with the Vulkan ICD Loader.
Okay, I think I got it. This is basically what I meant with “This seems to be deferred to the package managers of the distributions”, as in the way the files are packaged and distributed should make sure that if you have the
.pcfile you also get the libraries and headers and so on, which is the case with GLFW, since it includes everything, but not with Vulkan, since there are separate packages for the loader and the headers, and the.pcfile comes with the loader package.I guess one could make a distinction being able to link with a library and having the header file so that you compile against it, and that it’s not clear if having a
.pcfile for the library should always imply that you can both, so maybe this is Khronos’ take? (to be clear, I think it’s perfectly clear and that Vulkan is in the wrong here)Right, I wasn’t actually suggesting that Meson should do this, I just wasn’t sure how any build system looking at
.pcfiles were supposed to infer which headers are available since there is no information in them about headers.Anyways, thanks for the clarifications!