My other promised devils-advocate post: while you can have user or 3rd-party static libraries on macOS, the core OS libraries are not static. Even on Snow Leopard, libSystem was only dynamic; and on Catalina, I don't see ANY .a files in /usr/lib.
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). Still, it seems to me that if someone wants a MacPorts _derived_ executable that does not depend on a MacPorts installation, as long as the library dependencies also are provided in static form, it's possible, but their responsibility to figure out how to do that; perhaps via, as in previously posted example, a modified private Portfile. > On Dec 6, 2020, at 16:27, Dave Horsfall <[email protected]> wrote: > > On Sun, 6 Dec 2020, Riccardo Mottola via macports-users wrote: > >> I can think of two scenarios [ for static binaries ]: >> - building "always safe" binaries which can be used at system level, e.g. >> login shells, tools, things put in launchd. That is things you want to >> always work, even if you are during a MacPorts upgrade. NetBSD offers two >> packages for the same thing, e.g. bash and bash-static, IIRC. perhaps in >> MacPorts it could be a "variant"? > > Agreed; FreeBSD has an "/sbin" directory (and "/usr/local/sbin") containing > stuff that absolutely must be available, even in the lack of absence of > shared libraries. > > -- Dave >
