FYI, that's not how macOS app bundles work. While ELF binaries typically list the shared libraries they depend on with just a filename, Mach-O binaries use a p

FYI, that's not how macOS app bundles work. While ELF binaries typically list the shared libraries they depend on with just a filename, Mach-O binaries use a path. This can be an absolute path, which is typically used for OS-provided libraries. Or it can be a path relative to the binary containing the dependency, which is typically used for libraries contained in app bundles. (See the bottom of `man 1 dyld` for more info.) Thus there's no need to set environment variables just to run an app, and launchd doesn't do so. There is a variable called DYLD_LIBRARY_PATH, but it mostly exists for development/testing purposes. The way it works is that before the dynamic linker resolves a dependency path from a binary, it first searches DYLD_LIBRARY_PATH for a file matching the basename of the path, ignoring the rest of the path. Any such file will take precedence over the original path. I have seen some apps that rely on a wrapper shell script that sets DYLD_LIBRARY_PATH. I'm not sure if they just have the wrong dependency paths, or if they're dealing with other special cases like calls to dlopen with a bare filename.