[Bug c++/53068] collect2 breaks link order control

[igodard at pacbell dot net]

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)?