Compiling a port statically

[Richard L. Hamilton]

Of course, that also requires that every library port it depends on builds a static version as well as a shared version.

So I would imagine, even given the argument in favor of limited static executables, that there would be at most, very few indeed.

As others said recently, probably best not to use something other than a vendor (Apple) provided shell as a login shell; and a few other similar cases may also exist.

Using MacPorts (or self-compiled) alternatives to the dropped functions of macOS Server might, or might not, also be an area of concern. For myself, I'd use self-built ones with no more dependencies than necessary, as similar as possible to the ones Apple supplied back when they did, and strictly following their suggestions for alternatives to their dropped functionality.

> On Dec 6, 2020, at 10:31, Riccardo Mottola via macports-users <macports-users at lists.macports.org> wrote:
> 
> Hi,
> 
> 
> 
> On 12/5/20 8:07 AM, Ryan Schmidt wrote:
>>> Obviously the block would need some tweaking for a given port, it gives the idea.
>> I can't think of a reason why we would want to offer such a thing.
>> 
> 
> I can think of two scenarios:
> 
> - 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"?
> 
> - a special case of the above is an issue coming up on legacy MacOS more often where this happens with buildtools, e.g. a "static" version of certain tools which are more needed than on modern systems where the system ones are "good enough". When these build tools break MacPorts itself becomes much more a hassle itself to update
> 
> 
> 
> Riccardo
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macports.org/pipermail/macports-users/attachments/20201206/fd046704/attachment.htm>