> It is a delicate siuation, with Ken we were supposing to make a static > version or link statically, so that an upgrade does not "turn down" > all MacPort compilers. >
Ideally the compiler should have as few fragile deps as possible. Static linking in the compiler deps might help us get to a compiler that wouldn’t be broken by it’s own dep updates. You might think that it’s mantra to only use dylibs, but to be honest, the primary theoretical benefit of dylibs (updates in the library pass on to all users magically) seems to turn out to be fairly imaginary in the end, because as we have seen every significant dylib update requires everything that uses it to be revbumped and rebuilt anyway. There is the space/mem saving of dylibs — but static linking in the deps for a compiler would not be too onerous, as the deps are tiny indeed. libxml2 brings in a whole mess of stuff, including the nefarious ICU extravaganza, more complicated now because ICU requires a fairly recent compiler to bulid. There is no good reason for libxml2 to be a dep for clang/llvm as the system libxml2 does just fine. cmake brings in an amazing collection of deps, so cmake-bootstrap was invented, which has no external deps at all. cmake-bootstrap is new enough to build either llvm/clang-9.0 or possibly 10, I can’t remember just now if it could build 10. So that leaves libffi, libedit, ncurses, xar, zlib, and libcxx, which is a nice, small list of things that mostly build with the system compilers,, I believe, and — I think — almost all of them (not libcxx) can be statically linked in…. So it’s improvable, probably. Ken
