latest xcode 15.0 breaks loading from dylib: Symbol not found: _vkGetInstanceProcAddr

[rcoreilly]

Using VulkanSDK/1.3.239.0 version of MoltenVK library, building using the latest Xcode 15.0 which auto-updated recently, I now get this error:

dyld[53272]: Symbol not found: _vkGetInstanceProcAddr Referenced from: <708C9AD2-2D9E-3011-8AFE-30D2A2522304>

Anything linked prior to the XCode update works fine.

[rcoreilly]

workaround:

I downloaded Xcode 14.3.1 from here: https://developer.apple.com/download/all/ and then did xcode-select --install to install the command line tools, and it is back to working!

A colleague just did the command line tools 14.3.1 download and it didn't fix the problem -- it may be that just downloading the command line tools only replaces the symlinks but doesn't actually update the underlying code.

[kkoreilly]

This error also occurs when using the latest version of the Vulkan SDK, 1.3.261.1.

dyld[79594]: Symbol not found: _vkGetInstanceProcAddr
  Referenced from: <8F28F6F2-FD49-3D37-BE73-B7D794B87AA5> /Users/kaioreilly/goki/vgpu/examples/drawtri/drawtri
  Expected in:     <no uuid> unknown
Abort trap: 6

[cdavis5e]

Are your programs linked directly to MoltenVK, or to the Vulkan loader?

[rcoreilly]

directly linked to MotenVK.dylib, e.g.:

> otool -L drawidx
drawidx:
	/System/Library/Frameworks/Cocoa.framework/Versions/A/Cocoa (compatibility version 1.0.0, current version 23.0.0)
	/System/Library/Frameworks/IOKit.framework/Versions/A/IOKit (compatibility version 1.0.0, current version 275.0.0)
	/System/Library/Frameworks/IOSurface.framework/Versions/A/IOSurface (compatibility version 1.0.0, current version 1.0.0)
	/System/Library/Frameworks/QuartzCore.framework/Versions/A/QuartzCore (compatibility version 1.2.0, current version 1.11.0)
	/System/Library/Frameworks/Metal.framework/Versions/A/Metal (compatibility version 1.0.0, current version 306.5.16)
	@rpath/libMoltenVK.dylib (compatibility version 1.0.0, current version 1.0.0)
	/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 1500.65.0)
	/System/Library/Frameworks/CoreVideo.framework/Versions/A/CoreVideo (compatibility version 1.2.0, current version 1.5.0)
	/System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL (compatibility version 1.0.0, current version 1.0.0)
	/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 1971.0.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1319.100.3)
	/usr/lib/libresolv.9.dylib (compatibility version 1.0.0, current version 1.0.0)
	/System/Library/Frameworks/AppKit.framework/Versions/C/AppKit (compatibility version 45.0.0, current version 2299.50.120)
	/System/Library/Frameworks/CoreGraphics.framework/Versions/A/CoreGraphics (compatibility version 64.0.0, current version 1690.5.4)
	/System/Library/Frameworks/CoreServices.framework/Versions/A/CoreServices (compatibility version 1.0.0, current version 1228.0.0)
	/System/Library/Frameworks/Foundation.framework/Versions/C/Foundation (compatibility version 300.0.0, current version 1971.0.0)
	/usr/lib/libobjc.A.dylib (compatibility version 1.0.0, current version 228.0.0)

This is using Go, which runs the standard clang linker for external libs like this. I didn't try any other standard C++ examples while I had Xcode 15 installed. If nobody else is getting this problem, then it seems like it is an interaction with Go linking and the new Xcode, and I'll take it up with the Go folks..

[billhollings]

I've been using Xcode 15 (both beta and release versions), and I regularly use CTS, which make copious use of vkGetInstanceProcAddr(), and I haven't seen any linking issues arise with Xcode 15.

Just grasping at straws here, but is it possible that something in your environment is modifying how @rpath is handled?

[fknfilewalker]

I had a similar problem. Don't know if you're using cmake but setting

set(CMAKE_INSTALL_RPATH_USE_LINK_PATH ON)

fixed it for me.

Maybe the answer here can explain a few things: https://stackoverflow.com/a/47699417

[billhollings]

I had a similar problem. Don't know if your using cmake but setting

set(CMAKE_INSTALL_RPATH_USE_LINK_PATH ON)

fixed it for me.

Maybe the answer here can explain a few things: https://stackoverflow.com/a/47699417

Thanks very much for your suggestion, and the link to the thorough explanation!

[billhollings]

I've been using Xcode 15 (both beta and release versions), and I regularly use CTS, which make copious use of vkGetInstanceProcAddr(), and I haven't seen any linking issues arise with Xcode 15.

My response here was inaccurate, and the linked article above jogged my memory. I did have to deal with this for CTS with Xcode 15. I didn't correlate it with the errors above because the error messages I was seeing were different, and more obvious:

FATAL ERROR: Failed to open dynamic library: 'libvulkan.dylib'

To fix this I added the following environment variable to the CTS runtime environment:

export DYLD_LIBRARY_PATH=/usr/local/lib:$DYLD_LIBRARY_PATH

because /usr/local/lib is where the Vulkan SDK installs libvulkan.dylib and libMoltenVK.dylib. But DYLD_LIBRARY_PATH can be set to wherever the app bundles libMoltenVK.dylib.

Or, as suggested above, the CMAKE files can be edited directly for CMAKE_INSTALL_RPATH_USE_LINK_PATH.

I'll add some notes about this in the MoltenVK documentation.

[rcoreilly]

Thanks for the suggestions! Unfortunately for me, I think this is probably a different issue. If I rename the lib or change the DYLD_LIBRARY_PATH to exclude /usr/local/lib, then I get the more obvious error, e.g.,:

dyld[79285]: Library not loaded: @rpath/libMoltenVK.dylib
  Referenced from: <781F1DFA-C6C1-3965-9F1B-00EDC53EF477> /Users/oreilly/go/src/goki.dev/vgpu/v2/examples/drawidx/drawidx
  Reason: tried: '/usr/local/lib/libMoltenVK.dylib' (no such file), '/usr/lib/libMoltenVK.dylib' (no such file, not in dyld cache)

[asivitz]

It seems to be the case that the dynamic link loading in the xcode 15 toolchain won't look in /usr/local/lib for some reason. Downgrading to an xcode 14 toolchain fixed the problem for me (not finding libvulkan.so.1)

Not sure if that's a bug in the new linker or an intended change in behavior. Hopefully the former.

[rcoreilly]

If you're not using cmake, adding this: -Wl,-rpath,/usr/local/lib to the LDFLAGS during linking fixed the issue for me.

[SRSaunders]

This is coming a bit late in the discussion, but there is a cool utility called dylibbundler that allows you to change rpaths for referenced dylibs after building your app. I typically use this when creating macOS app bundles, where dylibs are moved into the Contents/libs directory of the bundle, and rpaths need adjusting to break dependencies on system install locations and create new executable-relative dependencies for standalone application delivery. I suspect you could use it to fix missing or broken references as per your case above.

Here is a sample of what things look like before and after running the utility:

Before:

$ otool -L MyApp.app/Contents/MacOS/MyApp
MyApp.app/Contents/MacOS/MyApp:
	@rpath/libMoltenVK.dylib (compatibility version 1.0.0, current version 1.0.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1319.100.3)
	/opt/local/lib/libSDL2-2.0.0.dylib (compatibility version 2601.0.0, current version 2601.5.0)
	/usr/local/opt/openal-soft/lib/libopenal.1.dylib (compatibility version 1.0.0, current version 1.23.1)
	/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 1500.65.0)

Command: $ dylibbundler -od -b -x MyApp.app/Contents/MacOS/MyApp -d MyApp.app/Contents/libs/

After:

$ otool -L MyApp.app/Contents/MacOS/MyApp
MyApp.app/Contents/MacOS/MyApp:
	@executable_path/../libs/libMoltenVK.dylib (compatibility version 1.0.0, current version 1.0.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1319.100.3)
	@executable_path/../libs/libSDL2-2.0.0.dylib (compatibility version 2601.0.0, current version 2601.5.0)
	@executable_path/../libs/libopenal.1.23.1.dylib (compatibility version 1.0.0, current version 1.23.1)
	/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 1500.65.0)

My just 2 cents in case this info is useful to others.