This is the mail archive of the
mailing list for the GCC project.
Re: at exit alternative for AIX
On Tue, Aug 7, 2012 at 1:42 PM, Perry Smith <firstname.lastname@example.org> wrote:
> Thanks. You just provide what I wanted / needed which is a sanity check.
> I'll open a bug report and that might get me some help.
> I think I've concocted a plan to get __cxa_atexit to work. I am going to try that
> first. That may have utility in other ways.
You also might want to look at PR 33704, as well as PRs 17053, 13391
and 2413. It would be good to figure out a way to utilize the patch in
The problem is AIX semantics is different than SVR4 semantics and GCC
should not assume that it is being used to link code expecting
GNU/Linux semantics. AIX invokes initializers in the order the
libraries are encountered while SVR4 wisely specifies initializers run
in the proper dependency order. IBM's C++ compiler works around this,
but it's name mangling, exception handling and initializers do not
follow G++ and the Itanium ABI conventions, so GCC cannot directly use
the same mechanisms.
One can merge the patch from PR 33704, but that raises the question of
when it should be used and what should be the default.
Use the option to build libstdc++? Okay.
Always use the option when linking with G++? Maybe.
Always use the option when linking with GCC? Probably not.
GCC is straddling the GNU/Linux and AIX environments. Should GCC
provide GNU/Linux behavior, IBM VAC++, or IBM XLC behavior? When?
A related situation that applied the GNU/Linux default of enabling
long double support to AIX caused numerous problems because of missing
library dependencies. G++/libstdc++ had to revert from GNU/Linux
default behavior to AIX default behavior because pushing against AIX
caused too many problems that could not be solved without
re-implementing more and more of the AIX runtime.
Users of GCC on AIX expect different, conflicting defaults and expect
GCC the do the right thing based on context, which is impossible in
Providing _cxa_atexit() using the existing finalizer function is the
right direction, but it still may run into problems due to the
lingering finalizer ordering bug. I am not trying to discourage you
-- on the contrary I want to encourage you -- but I also want to
introduce some context.