http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53068
--- Comment #4 from Ivan Godard <igodard at pacbell dot net> 2012-04-22 06:08:28 UTC --- Looking a little further at this, I don't think we can use init_array at all, even if it ran in reverse order. Consider TUs in a .a library, where some of the TUs have an order dependency with other TUs in the same library. If I understand the way init_array works (doubtful), the init_array will be populated with TUs in command line order; the assumption is that libraries at the end of the list are more primitive, and so will need to be initialized first. Or maybe the order is reversed; either way, it is determined by the command line. However, if several TUs are picked up from a single library then they will be ordered w/r/t files from a different library, but will be in random order w/r/t files from the same library. This breaks the asserted intra-library dependency. As far as I can tell from the discussion there is no way to control the init_array populating process other than priority, which as previously mentioned is unusable in a large environment with third-party binaries. Hence we need some way to force gcc to continue to use ctors instead of init_array. I find no documented option to do that - have I overlooked it, or does it not exist? Or have I misunderstood init_array (all to likely)?
