The loader is responsible for mapping an application to Vulkan layers and Vulkan installable client drivers (ICD).
The Vulkan headers only provide the Vulkan function prototypes. When building a Vulkan application you have to link it to the loader or you will get errors about undefined references to the Vulkan functions. There are two ways of linking the loader, directly and indirectly, which should not be confused with “static and dynamic linking”.
Directly linking at compile time
This requires having a built Vulkan Loader (either as a static or dynamic library) that your build system can find.
Build systems (Visual Studio, CMake, etc) have documentation on how to link to the library. Try searching “(InsertBuildSystem) link to external library” online.
Indirectly linking at runtime
Using dynamic symbol lookup (via system calls such as
dlopen) an application can initialize its own dispatch table. This allows an application to fail gracefully if the loader cannot be found. It also provides the fastest mechanism for the application to call Vulkan functions.
Volk is an open source implementation of a meta-loader to help simplify this process.
Each platform can set its own rules on how to enforce the Vulkan Loader.
Android devices supporting Vulkan provide a Vulkan loader already built into the OS.
A vulkan_wrapper.c/h file is provided in the Android NDK for indirectly linking. This is needed, in part, because the Vulkan Loader can be different across different vendors and OEM devices.
The Vulkan SDK provides a pre-built loader for Linux.
The Getting Started page in the Vulkan SDK explains how the loader is found on Linux.
The Vulkan SDK provides a pre-built loader for MacOS
The Getting Started page in the Vulkan SDK explains how the loader is found on MacOS.