Compiling a port statically

[Riccardo Mottola]

Hi Ryan,

Ryan Schmidt wrote:
>> - 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"?
> No, we should not offer a variant of any port to do a static build. Static build means all of the libraries that a program depends on are copied into the program executable. That means if we later update one of those libraries to a newer version, the statically-built program will not benefit from those fixes, unless its revision is increased to rebuild it, but whoever updated the library would not know that that needs to be done. We should not introduce more situations into MacPorts where developers updating library ports need to know about increasing the revisions of ports that use the library. Instead we should do the opposite, identifying those ports that only build a static library and fixing them so that they also or instead build a dynamic library so that ports that link with them can benefit from new versions without needing to be rebuilt.

Indeed, you are right, a "variant" here would indeed be an issue I 
didn't think about.
We should not replace a dylib with it static version, we should provide 
both, one possibly used only for build reason.

Under the assumption that "static libraries" are of no real interest if 
not to build static commands and that these should remain a minority in 
your installed ports, it should be a different thing

E.g. suppose libA is needed by many ports, we install it as shared and 
right so.
However tool X needs libA and if you want toolX as static, its dependent 
static library libA should be built *also* as static. Technically, once 
built, the static library could be even removed.
So it is only a "build" dependency.

If libA gets an update, no lookup can tell you to update toolX, but this 
side effect is also the goal - toolX will continue working (but might 
have a security issue or whatever). Another command to look up toolX 
could envisioned, but toolX would continue working and that is the 
important thing.

Riccardo