Feedback was submitted on FB13226043 Oops, I've also submitted mine (didn't see @pwramsey3 submitting theirs), mine is FB13233867

@eskimo In our case there's a minor difference, we don't use rpath, but overall the process is similar: Create a dynamic library called libfoo.dylib with an install name of libfoo.dylib (no rpath) Install that in /usr/local/lib. Create a binary that calls a symbol exported by that dynamic library. Interestingly, linker works fine, in our case its go compiler - it can find this library without issues even if it's install path is just the file name. This means linker can search /usr/local/lib by default. However when running the newly built binary, dyld fails to locate it. This used to work. My understanding is that dyld used to search /usr/local/lib by default. According to man dyld description of DYLD_FALLBACK_LIBRARY_PATH: If a dylib is not found at its install path, dyld uses this as a list of directories to search for the dylib. By default, it is set to /usr/local/lib:/usr/lib. If this change is intentional, man page should probably be updated, or if not, it seems like a bug? Long-worded thread in pact-go github: https://github.com/pact-foundation/pact-go/issues/345 \

I can confirm this behavior, and that it started causing troubles with the recent XCode update. Ran into it with pact-go, which installed a libpact_ffi.dylib under /usr/local/lib with install_name being just libpact_ffi.dylib. Long-winded post here - https://github.com/pact-foundation/pact-go/issues/345 According to dyld man page, this should work, because /usr/local/lib is in the default fallback search paths - and it used to work ok. Have you opened a ticket with Apple already @pwramsey3 ?