Compiling a port statically
cal at macports.org
Mon Dec 7 00:47:59 UTC 2020
On Sun, Dec 06, 2020 at 05:32:12PM -0500, Richard L. Hamilton wrote:
> So on macOS, if you're worried more about breakage in the absence of
> shared libraries than in updated-ness/correctness, you can IN
> PRINCIPLE statically link with non-OS libraries, and only dynamically
> link with the minimum needed OS libraries. That at least gives you an
> executable that has no runtime dependencies outside of the OS (and of
> course any hard-coded paths or configuration files the executable
> might expect).
If you're worried about this scenario, it is much easier to create a
copy of whatever binary you're trying to compile statically and bundle
it with its dependent libraries. That does not require changing any of
the ports (except for building with -Wl,-headerpad_max_install_names,
which MacPorts already does for you to support relocation and bundling
of such libraries).
There's even a port in macports called dylibbundler that automates
adjusting the dylib load commands to do this.
This entire thread is discussing the feasibility of a single solution to
a problem, without taking a step back and checking whether there are
other and potentially simpler solutions for the problem.
Yes, statically linking non-system libraries can be done on macOS, but
it is hardly ever done (just look at every .app bundle out there), not
simple, not well-supported by MacPorts, and there are better
More information about the macports-users