Bundles up all dependencies used by an executable (or library) into a single folder, and patches all of the executables to look in that directory so you don't have to rely on your users having certain libraries installed.
Part of my motivation in making this was to learn Python 3's async/await, too. The processes that are used to patch stuff and query dependencies all run in parallel so it should be super fast!
You need:
- Python 3 (
brew install python3) because it uses async/await and asyncio - Xcode CLI tools (I think)
The easiest way to get going is by installing through pip + PyPi:
pip3 install macpack
macpack <your executable here>
You can also run it out of the project directory by doing:
macpack/patcher.py <your executable here>
It should print the dependency tree like this example:
$ macpack ~/Code/node-canvas/build/Release/canvas.node
Patching /Users/caleb/Code/node-canvas/build/Release/canvas.node
16 total non-system dependencies
1 libpixman-1.0.dylib -> 1
2 libcairo.2.dylib -> 2, 1, 16, 9, 3
3 libpng16.16.dylib -> 3
4 libpangocairo-1.0.0.dylib -> 4, 5, 2, 14, 6, 13, 7, 8, 15, 16, 9
5 libpango-1.0.0.dylib -> 5, 6, 13, 7, 8
6 libgobject-2.0.0.dylib -> 6, 7, 11, 12, 8
7 libglib-2.0.0.dylib -> 7, 11, 8
8 libintl.8.dylib -> 8
9 libfreetype.6.dylib -> 9, 3
10 libjpeg.8.dylib -> 10
11 libpcre.1.dylib -> 11
12 libffi.6.dylib -> 12
13 libgthread-2.0.0.dylib -> 13, 7, 11, 8
14 libpangoft2-1.0.0.dylib -> 14, 5, 6, 13, 7, 8, 15, 16, 9
15 libharfbuzz.0.dylib -> 15, 7, 8, 9
16 libfontconfig.1.dylib -> 16, 9
canvas.node + 16 dependencies successfully patched
Everything that your executable uses should then be copied into the same folder
that your binary is. When your main binary is run next, it will look in the new
location you specified (default is binary_dir/libs/<lib>, see -d below).
Those dylibs will look in the same directory for dylibs they depend on, too, even
if your main binary does not use them.
You can then distribute the whole folder as one.
Pass -v to get output from otool if it failed to patch or more information on
which dependencies could not be loaded.
It will also print a more easy to read dependency tree, with the full names of dependenies under each one
This is the destination folder relative to the binary's containing folder to
copy library dependencies to. For example, if you binary is /a/b/program,
and you pass -d ../libraries, they will copy to and load from
/a/libraries/. The default value is ../libs.
If you want the executable and libraries to have absolute paths instead of loading
relative to the binary, you just need to specify an absolutep path for -d. In
that case the @executable_path will not be put into the binaries at all.
Just prints the dependency tree and doesn't do any patching. Use -nv to get a
slightly more user-friendly tree printed out.
It will parse out the executable's dependencies (using otool -L) and their
dependencies recursively, filtering out system libraries. When the tree
is built, it will copy the libraries to your program's folder and then patch
everything that it is aware of (using install_name_tool). It should be able
to handle different symbolic links and all that correctly
Inspired by macdylibbundler, it does the same basic thing except with less options (at the moment) and it builds a full dependency tree