On Thu, Aug 22, 2013 at 11:12 AM, Jonathan S. Shapiro <[email protected]> wrote:
> The main problem that the second approach doesn't solve is run-time loading > of unregistered code. That is: code where the dependency between the > application and the thing it loads is only recorded in a string somewhere > that is getting passed to LoadDynamicLibrary() or some such thing. I'm > frankly not convinced that this issue is all that serious. First, I'm not > sure that promiscuous dynamic loading is a good idea from a security > perspective. But even if it is, we can register such libraries as "might be > loaded by *", do the post-install AOT thing, and not drop the old version > until all applications in the system have been recompiled. It's not pretty, > but it would work. there are the cases where library x is dynamically loaded by prog a unknowingly given library x's standard interface for AOT linking, in order to solve the situation that library x has some static state which prog a needs 2 of, or that prog a depends on multiple versions of the library x standard interface. this situation is quite ridiculous though, turning your statement into 'x.i might be loaded by a', I think most if not all uses of dynamic library opening can be attributed to the compilation tools themselves, their reliance on the filesystem promotes building fences around plots of code, the lack of whole system compilation turns into optional dependencies for convenience. I don't know but it seems like a subset of the problems for a minimally expansive incremental compilation (an attempt to restate it in a way which isn't tainted by the mess we have made) _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
