Vulkan loader order is wrong/broken on osx?

[mokafolio]

This PR correctly raised concerns over here:
#14503

Right now Cocoa_Vulkan_LoadLibrary probes @executable_path/../Frameworks/libMoltenVK.dylib first and treats a successful dlopen as "the app bundles MoltenVK". That is not an existence check: dyld resolves every load request by leaf name against DYLD_LIBRARY_PATH before trying the path as written (this includes @executable_path/...).

The Vulkan SDK's setup-env.sh puts $VULKAN_SDK/lib (which contains libMoltenVK.dylib) on DYLD_LIBRARY_PATH meaning that the current mechanism circumvents the loader infrastructure for every bare binary on machines that want to use the regular Vulkan SDK infrastructure (because moltenvk is found via DYLD_LIBRARY_PATH, consequently always skipping the loader).

Long story short, I believe volk reverting this logic (see zeux/volk#268) is the (more) correct behavior.

A resolution logic along the following lines should be able to satisfy both:

• Check @executable_path/../Frameworks/libMoltenVK.dylib first, so an app that ships MoltenVK still wins.
• Before calling dlopen on it, check if the file is actually there relative to the executable, skip otherwise
• With that check the behavior is: bundle present → bundled MoltenVK; no bundle → libvulkan.1.dylib via the loader (I believe this is similar to SDL2)

Happy to discuss this further and open a PR with improved resolution logic if it helps.

[slouken]

Sure, feel free to create a (non-AI) PR to address this.

Thanks!

[mokafolio]

excuse the ai commit message on 7c81b3b. I worked on main and used clanker to commit it to my fork remote after the fact but the actual edits to SDL_cocoavulkan.m were hand made.