-
batterseapower authored
When a plugin is loaded, it currently gets linked against a *newly loaded* copy of the GHC package. This would not be a problem, except that the new copy has its own mutable state that is not shared with that state that has already been initialized by the original GHC package. This leads to loaded plugins calling GHC code which pokes the static flags, and then dying with a panic because the static flags *it* sees are uninitialized. There are two possible solutions: 1. Export the symbols from the GHC executable from the GHC library and link against this existing copy rather than a new copy of the GHC library 2. Carefully ensure that the global state in the two copies of the GHC library matches I tried 1. and it *almost* works (and speeds up plugin load times!) except on Windows. On Windows the GHC library tends to export more than 65536 symbols (see #5292) which overflows the limit of what we can export from the EXE and causes breakage. (Note that if the GHC exeecutable was dynamically linked this wouldn't be a problem, because we could share the GHC library it links to.) We are going to try 2. instead. Unfortunately, this means that every plugin will have to say `reinitializeGlobals` before it does anything, but never mind. I've threaded the cr_globals through CoreM rather than giving them as an argument to the plugin function so that we can turn this function into (return ()) without breaking any plugins when we eventually get 1. working.
0e765db4