Hi Al. I have had another look at the pending dispatcher rework which was meant to provide dynamically allocated dispatchers.
There is some overlap with randomised static construction order mitigation. As Christian pointed out correctly, we should not rely on the construction order, as more linkers tend to behave randomly. The rework had introduced a tweak that created the _map instance on demand. the intent was to defer the crash, while printing the link order warning. The crash was then caused during shutdown, because the map was deleted before all content was uninstalled. There are two ways around it. 1 don't delete _map (in static instances). _map will be deleted anyway, so there is no difference in production builds. But in a debugging build, we also check if all contents are gone, before deleting _map. This will now lead to false positives, if the link order is wrong. 2 make sure objects are installed after dispatcher creation. This would basically mean that the library needs to be split. globals would have to become part of main, or the "internal" plugins would have to become loaded like the default plugins. I dislike 2, hence I implemented 1 (see link_order branch). Please have a look if this is good enough for develop. NB: the reason we postponed the dynamic dispatchers was the interface incompatibility. this can be easily avoided by just using the old dispatcher header (on an unaffected platform). cheers felix _______________________________________________ Gnucap-devel mailing list Gnucap-devel@gnu.org https://lists.gnu.org/mailman/listinfo/gnucap-devel
