<html><head><meta http-equiv="Content-Type" content="text/html; charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Of course, that also requires that every library port it depends on builds a static version as well as a shared version.<div class=""><br class=""></div><div class="">So I would imagine, even given the argument in favor of limited static executables, that there would be at most, very few indeed.</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">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.<br class=""><div class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Dec 6, 2020, at 10:31, Riccardo Mottola via macports-users <<a href="mailto:macports-users@lists.macports.org" class="">macports-users@lists.macports.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class="">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" class="">
<div class=""><p class="">Hi,</p><p class=""><br class="">
</p>
<div class="moz-cite-prefix">On 12/5/20 8:07 AM, Ryan Schmidt wrote:<br class="">
</div>
<blockquote type="cite" cite="mid:C08479A3-4A10-4D21-8DED-6AB10DD619EB@macports.org" class="">
<blockquote type="cite" style="" class="">
<pre class="moz-quote-pre" wrap="">Obviously the block would need some tweaking for a given port, it gives the idea.
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">I can't think of a reason why we would want to offer such a thing.
</pre>
</blockquote><p class=""><br class="">
</p><p class="">I can think of two scenarios:</p><p class="">- 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"?<br class="">
</p><p class="">- 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</p><p class=""><br class="">
</p><p class="">Riccardo<br class="">
</p>
</div>
</div></blockquote></div><br class=""></div></div></body></html>