http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53068
Paul Pluzhnikov changed:
What|Removed |Added
CC||ppluzhnikov at google dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53068
Pawel Sikora changed:
What|Removed |Added
CC||pluto at agmk dot net
--- Comment #7 from
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53068
--- Comment #6 from Ivan Godard 2012-04-22
07:46:20 UTC ---
Yes, but. Order is not defined, but order dependencies are inescapable in C++
which has a tendency to invoke constructors where you least expect them - when
you #include a file for examp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53068
--- Comment #5 from Andrew Pinski 2012-04-22
07:19:29 UTC ---
Really you should not be dependent on the order since that has even been
defined. Yes you would think it would be defined but it was never a guarantee.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53068
--- Comment #4 from Ivan Godard 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 depende
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53068
--- Comment #3 from Ivan Godard 2012-04-22
04:49:46 UTC ---
Wow - this will break a lot of big users - we are far from the only ones who
find priorities unusable.
BTAIM, it appears that our choice is to use an option (there is one? what?) to
for
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53068
--- Comment #2 from Andrew Pinski 2012-04-22
03:56:07 UTC ---
See http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770#c76 for more info.
Really any dependance on link order is invalid for C++ code.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53068
--- Comment #1 from Andrew Pinski 2012-04-22
03:53:53 UTC ---
I don't think this is collect2 changing the order but rather .init_array which
changes the order.
