bug: MacOS Intel can't find Vulkan libraries

[riktam]

Version: e.g. 0.7.1

Describe the Bug

App can't find libvulkan.dylib . I have the lib linked on /usr/local/lib/ which is the path where Vulkan SDK (1.4.328.1) installs the lib. DYLD_LIBRARY_PATH seems not to be considered in the search path.

It's no longer possible to make links in /usr/lib to avoid the issue.

Steps to Reproduce

1. start app in MacOS Sequoia 15.7.1 Intel

Screenshots / Logs

[21:15:16] ERROR Failed to get Vulkan GPUs: LibraryLoadFailure(DlOpen { desc: "dlopen(libvulkan.dylib, 0x0005): tried: 'libvulkan.dylib' (relative path not allowed in hardened program), '/System/Volumes/Preboot/Cryptexes/OSlibvulkan.dylib' (no such file), '/usr/lib/libvulkan.dylib' (no such file, not in dyld cache), 'libvulkan.dylib' (relative path not allowed in hardened program)" }) [21:15:16] ERROR Failed to get Vulkan GPUs: LibraryLoadFailure(DlOpen { desc: "dlopen(libvulkan.dylib, 0x0005): tried: 'libvulkan.dylib' (relative path not allowed in hardened program), '/System/Volumes/Preboot/Cryptexes/OSlibvulkan.dylib' (no such file), '/usr/lib/libvulkan.dylib' (no such file, not in dyld cache), 'libvulkan.dylib' (relative path not allowed in hardened program)" })

Operating System

• [X ] MacOS
• [ ] Windows
• [ ] Linux

I'm hoping that this fix would allow for vulkan accelerated LLMs on OSX intel.

[james-see]

Some nuance here and options if anyone wants to try to fix:

Fix options:

1. Bundle Vulkan and set rpath • Copy the Vulkan loader dylib into your app bundle, e.g.: ▫ MyApp.app/Contents/Frameworks/libvulkan.dylib • Set an rpath so the loader is found at runtime: ▫ Add -rpath @executable_path/../Frameworks (or @loader_path/../Frameworks) to your link flags. • If you link to libvulkan at build time, change its install_name so the app looks in your Frameworks dir: ▫ install_name_tool -change /usr/local/lib/libvulkan.dylib @rpath/libvulkan.dylib MyAppBinary • Codesign the app including the bundled lib: ▫ codesign –force –options runtime –deep –sign “Developer ID Application: Your Name” MyApp.app • Optionally embed entitlements if needed (com.apple.security.files.user-selected.read-only for file access, etc.).

2. Use dynamic runtime discovery and CFBundleExecutable-relative path • Don’t link directly to libvulkan; dlopen it at runtime from the app bundle: ▫ Try @rpath/libvulkan.dylib then fall back to @loader_path/../Frameworks/libvulkan.dylib. • Ensure you set the hardened runtime but avoid relative paths outside the bundle. • This reduces dependency on system-wide locations.

3. Point the Vulkan loader to the SDK via VK_ICD_FILENAMES/VK_DRIVER_FILES • On macOS, MoltenVK is typically the ICD: ▫ Export VK_ICD_FILENAMES to the absolute path of MoltenVK_icd.json inside the SDK. • However, hardened runtime still won’t allow loading libraries via DYLD_* from arbitrary locations. Prefer bundling MoltenVK and the loader into the app.

4. Homebrew path and install_name sanity check • If you rely on Homebrew (not recommended for a hardened, distributable app), verify: ▫ otool -L MyAppBinary ▫ otool -l MyAppBinary | grep -A2 LC_RPATH ▫ Ensure you see @rpath/libvulkan.dylib and an LC_RPATH that points to your app’s Frameworks. • If it shows /usr/local/lib/libvulkan.dylib, fix with install_name_tool and add -rpath.

5. Codesign properly • Hardened runtime blocks loading unsigned libraries and relative paths. • Sign the entire bundle, including libvulkan.dylib and MoltenVK: ▫ codesign –force –options runtime –deep –sign “Developer ID Application: Your Name” MyApp.app • Verify: ▫ codesign –verify –deep –strict –verbose=2 MyApp.app ▫ spctl –assess –type execute –verbose MyApp.app