C++ module ordering (was: segmentation fault on GiNaC-1.2.0 using MinGW on Win XP)

[Ian Lance Taylor]

"Richard B. Kreckel" <kreckel at ginac.de> writes:

> So it remains a mystery what was meant by "full runtime dependency
> analysis [...] with no linker mods"?  Sad.

Oh, no, I know what that means.  It means that the compiler itself
looks at the constructor and determines what other objects it
references.  The compiler itself then ensures that any constructor for
those other objects are run first.  The compiler should be able to do
a more reliable job than the linker.

One way to do that would for the compiler to generate entries in a
special section for each global constructor.  Each entry in the
section would simply be the name of the global constructor and the
name of another object upon which it depends.  The linker could then
gather that information together and build a topographical map, and
use that map to construct a constructor ordering, much as is done in
Bruno's existing patch.  Circular dependencies would be detected at
link time.

> > Are you familiar with the init_priority attribute supported by g++?
> > It seems to me that it handles most of the problems associated with
> > static object initialization order.
> >     http://gcc.gnu.org/onlinedocs/gcc-3.4.0/gcc/C---Attributes.html#C++%20Attributes
> 
> Sure, but that is only pampering about the real problem: Who establishes
> the PRIORITY variables?  The programmer would have to do it manually.
> Any programmer is likely to get it wrong if confronted with several
> hundreds or even thousands of modules.  Working with an automated
> mechanism is much less prone to errors.  Hence init_priority is not at all
> an acceptable solution, IMNSHO.

Well, even with many modules, you can divide and conquer the problem.
Normally modules come in groups, and you can determine a topographical
sort of the group.  Then you can assign number ranges to the groups.
Then within each group, you can do the right thing.  If there are
circles in the group graph, then you have a problem, but in that case
I suspect that you have a deeper design problem as well.

The other simple approach is to not use global constructors, or at
least not global constructors in which there are cross-module
dependencies.  You instead pay a cost to check that the objects are
initialized before they are used.  In practice I suspect this cost
would be quite small.

Ian