Defined VK_VERSION_1_3 causes linker problems while building for iOS

[squadack]

MoltenVK is an implementation of Vulkan 1.1 but the supplied headers define VK_VERSION_1_3, which causes some libraries to expect a feature which isn't implemented. This causes an error while linking with MoltenVK framework for iOS, as it's missing some symbols (in my case vkGetDeviceBufferMemoryRequirements and vkGetDeviceImageMemoryRequirements).
Shouldn't MoltenVK define only versions up to VK_VERSION_1_1?

[spnda]

What the headers provide and what an implementation actually supports are two totally different and unrelated things. It's perfectly fine to use a 1.3 header with a 1.0 implementation, or vice versa. In this case, you are statically linking and VMA therefore tries to link to the prototype defined in the Vulkan header, even though it does not exist. Either you #undef VK_VERSION_1_3 before you include the VMA header or you will have to dynamically load Vulkan function pointers at runtime using vkGet*ProcAddr (which I wholeheartedly recommend doing). If you use a library like volk this process is extremely simple anyway. It also seems like it is possible for VMA to do the function loading itself by defining VMA_DYNAMIC_VULKAN_FUNCTIONS. That will require you to pass the library vkGet*ProcAddr when calling vmaCreateInstance and it will then load all other function pointers itself instead of statically linking.

And no, MoltenVK should definitely continue using up-to-date headers which will continue to include the VK_VERSION_1_3 definition.

[billhollings]

As @spnda indicates, MoltenVK can't just use a header from VK_VERSION_1_1, as we need access to extension function and structure declarations beyond core functionality.

What happens to VMA with links to Vulkan extension functions that are not part of core? Those are also declared in the headers, but not all are implemented by MoltenVK. Do they not break the linkages from VMA?