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

[Gabriel Dos Reis]

Ian Lance Taylor <ian at wasabisystems.com> writes:

| "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.

I suspect Ricky's point is preceily that if that sektch of algorithm
is workable, then it should be tajen care of by the compiler -- those
are simply too much of low level details and the compiler/linker has
more information that it could pass around.  

|  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.

yep, but then it would be helpful if such circles are reported by the
compiler/linker as it is processing the translation/instantiation
units.  In presence of templates and "deferred" instantiations, that
even makes more sense where one gets all sorts of headaches.  See

    http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/cwg_defects.html#362
    http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/cwg_defects.html#270

| 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.

Well, I'm not sure :-)

-- Gaby