* Jonathan S. Shapiro: > On Mon, Aug 26, 2013 at 1:13 PM, Florian Weimer <[email protected]> wrote: > >> But there is a class of users who want documentation for *any* change. >> I'm not sure how they will react to, say, a TLS library update that >> comes with the library update *and* most packages in the distribution >> which have been "rebuilt due to a change in dependencies".
> Why on earth would you do *that*? It's the reality today with GHC and Go (both Google compilers). It used to be this way with various Common Lisp implementations. > But to be clear, my assumption is that the recompile happens on the > system that is the target of install, and is performed by an AOT > compiler that is a core component of that system. Yes, that's what common-lisp-controller did, and to a lesser degree, ASDF. It led to occasional problems, just like class loading errors as the result of binary compatibility violations in Java. Despite that, it's probably the way forward for GHC and Go, with some restrictions. (These language implementations can mix in C code which is not fully separately compiled, so that without further measures, you need full C development environment at installation time, not just the language environment or a smart linker.) Speaking of linking, there is the ELF prelinking optimization which performs ahead-of-time linking to avoid run-time relocations, using system-specific load addresses. It causes endless headaches for cryptographic libraries in FIPS mode because the hash-based tampering fails. This might be a misapplication of the FIPS requirements (especially considering the way these requirements are applied to extremely dynamic environments with run-time code redefiniton etc.), but it's the current state of the art. _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
