**dylibbundler** is a macOS command-line utility for producing relocatable application bundles. External dependencies (dynamic libraries) are copied inside the app bundle, and install names are made run-path-relative. (https://developer.apple.com/library/archive/documentation/DeveloperTools/Conceptual/DynamicLibraries/100-Articles/RunpathDependentLibraries.html)
Executable file or dynamic library (ex: .dylib, .so) to fix. Any file on which `otool -L` works is accepted by `-x`. dylibbundler will walk through the dependencies of the specified file to build a dependency list. It will also fix the said files' dependencies so that it expects to find the libraries relative to itself (e.g. in the app bundle) instead of at an absolute path (e.g. /usr/local/lib). To pass multiple files to fix, simply specify multiple `-x` flags.
Copy framework dependencies to app bundle and fix internal names and rpaths. If this option is not passed, dependencies contained in frameworks will be ignored. dylibbundler will also deploy Qt frameworks & plugins, eliminating the need to use `macdeployqt`.
> Sets the "inner" installation path of libraries, usually inside the bundle and relative to executable. (Default is `@executable_path/../Frameworks`, which points to a directory named `Frameworks` inside the `Contents` directory of the bundle.)
*The difference between `-d` and `-p` is that `-d` is the location dylibbundler will put files in, while `-p` is the location where the libraries will be expected to be found when you launch the app (often using @executable_path, @loader_path, or @rpath).*
> Dylibs in (path) will be ignored. By default, dylibbundler will ignore libraries installed in `/usr/lib` & `/System/Library` since they are assumed to be present by default on all macOS installations. *(It is usually recommend not to install additional stuff in `/usr`, always use ` /usr/local` or another prefix to avoid confusion between system libs and libs you added yourself)*
