For context, executable binaries have compiled within them the folder locations(s) to use when searching for dylibs at runtime. These locations can be seen with either otool -l path/to/binary or otool -L path/to/binary after compilation, and show listings for each dylib in the executble. Some listings may be prefixed with @rpath (as in @rpath/path/to/dylib.dylib), representing a dynamic location. (This is related to LC_RPATH (the "load command" that sets the rpath at runtime) which was included in the error message presented at runtime.)
Since XCode 15, the system (somewhere in the udpated tools) will no longer use /usr/local/lib as a fallback or default location when searching for dylib files (it appears to be a security concern). It's unclear if this change is categorized as an unintended bug (I read the linker was completely rewritten to be faster), or a policy change.
Several possible changes are considered to fix this issue.
Option 1: Set a rpath during compilation
This can be done by including the flag -rpath '/usr/local/lib' during invocation of clang/g++ (e.g. something like g++ main.o -I./include -L./libs -rpath '/usr/local/lib'). The order or placement of -rpath flag does not appear to matter.
Option 2: Set a rpath after compilation
This can be done with $> install_name_tool -add_rpath /usr/local/lib path/to/binary
Setting a DYLN_LIBRARY_PATH, or LD_LIBRARY_PATH, or LDFLAGS, or modifying $PATH or other global or environment variables did not appear to solve the problem.
Rebuilding and reinstalling dependent libraries after upgrade to XCode 15.0 did not fix the issue
Resetting XCode (xcode-select -r) did not fix the issue
I read through XCode 15 Release Notes and didn't find anything mentioned other than a rewrite of the linker.
Attempting to export LD_LIBRARY_PATH=/lib:/usr/lib:/usr/local/lib did not appear to work (though attempting again in the future might be worth at try).
Solution
For blast/Makefile, I've decided to explicitly set the rpath when building in MacOS to /ur/local/lib. For my build environment, this is where all the libs are located (liballegro_font.dylib, et all). Note that Mac's -framework dylibs are already available by being included in a protected cache on the mac, so they are automatically found at runtime (unless explicitly declared to be found elsewhere).
According to "The Eskimo!" from Apple, going forward, all compiled binaries should prefer to have known locations for the dylibs they are relying on, and should not rely on implicit locations for security reasons (source).
Problem
Since updating to XCode command line tools 15.0, a change in the linker behavior required a patch to this project's Makefile.
For context, executable binaries have compiled within them the folder locations(s) to use when searching for dylibs at runtime. These locations can be seen with either
otool -l path/to/binaryorotool -L path/to/binaryafter compilation, and show listings for each dylib in the executble. Some listings may be prefixed with@rpath(as in@rpath/path/to/dylib.dylib), representing a dynamic location. (This is related toLC_RPATH(the "load command" that sets the rpath at runtime) which was included in the error message presented at runtime.)Since XCode 15, the system (somewhere in the udpated tools) will no longer use
/usr/local/libas a fallback or default location when searching for dylib files (it appears to be a security concern). It's unclear if this change is categorized as an unintended bug (I read the linker was completely rewritten to be faster), or a policy change.Several possible changes are considered to fix this issue.
Option 1: Set a rpath during compilation
This can be done by including the flag
-rpath '/usr/local/lib'during invocation ofclang/g++(e.g. something likeg++ main.o -I./include -L./libs -rpath '/usr/local/lib'). The order or placement of-rpathflag does not appear to matter.Option 2: Set a rpath after compilation
This can be done with
$> install_name_tool -add_rpath /usr/local/lib path/to/binaryOther solutions proposed
DYLN_LIBRARY_PATH, orLD_LIBRARY_PATH, orLDFLAGS, or modifying$PATHor other global or environment variables did not appear to solve the problem.xcode-select -r) did not fix the issueexport LD_LIBRARY_PATH=/lib:/usr/lib:/usr/local/libdid not appear to work (though attempting again in the future might be worth at try).Solution
For
blast/Makefile, I've decided to explicitly set therpathwhen building in MacOS to/ur/local/lib. For my build environment, this is where all the libs are located (liballegro_font.dylib, et all). Note that Mac's-frameworkdylibs are already available by being included in a protected cache on the mac, so they are automatically found at runtime (unless explicitly declared to be found elsewhere).According to "The Eskimo!" from Apple, going forward, all compiled binaries should prefer to have known locations for the dylibs they are relying on, and should not rely on implicit locations for security reasons (source).
Some links
@rpath(and other similar variables) in the as shown withotool: https://wincent.com/wiki/%40executable_path%2C_%40load_path_and_%40rpathotool,install_name_tool, etc for setting/reading/etc library info: https://www.ill.eu/about-the-ill/contacts/public-relations/afilhol/macos-development/useful-commands