http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770
Ivan Godard <igodard at pacbell dot net> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |igodard at pacbell dot net
--- Comment #96 from Ivan Godard <igodard at pacbell dot net> 2012-04-22
08:01:55 UTC ---
I'm a user that the switch to init_array just broke. Details are in
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53068, but to summarize:
Large production environment
Must use other compilers too
Third party binaries as well as our code.
Each project represented as a .a library.
Static initialization dependencies between TUs in a project (and hence within
.o's in a library).
Static initialization dependencies among projects.
Executables link some explicit .o's with libraries from other projects, and
must provide semantically correct ordering.
Hence:
Can't use priorities (not supported on other compilers; can't add pragmas to
3rd party code; maintaining a global absolute order over hundreds of files that
change dependencies each release is a headache)
Can't use init_array (no way to control ordering among files extracted from a
single library)
So for a decade we have manually maintained a dependency graph (relative, not
absolute like priorities) and used that to put explicit commands to position
.ctor sections into a linker script.
That broke in 4.7.
Yes, the language leaves inter-TU order unspecified. But we the users have to
control that particular unspecified to get our job done. There used to be a way
to exercise that control, through hooks in the linker script. You have now
gratuitously taken away that control *and left nothing else to use instead*.
At this point our choices appear to be to stay at 4.6 forever (or at least
until the roar of complaint makes you do something), or to do our own collect2.
Pretty poor.
