On Aug 8, 2012, at 3:32 PM, David Edelsohn wrote: > On Tue, Aug 7, 2012 at 1:42 PM, Perry Smith <pedz...@gmail.com> 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. > > Perry, > > 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 > PR 33704. > > 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? > Which default? > > 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 > this situation. > > 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.
I finally created my bug report and supplied the changes that I'm using: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54601 I added __cxa_atexit to libstdc++ which I believe will be a good feature for the few platforms like AIX that do not already have it. Off topic: There is a subtle "who cares" type of bug in the configure script. When it tries to detect if __cxa_atexit is present, it does not link with libstdc++. It seems like __cxa_atexit is only used for c++ and so my thoughts are that the detection should use c++ instead of just c. I reviewed the other defects and thought about some of the issues. I think my current issue is somewhat orthogonal to the others. i.e. it can be implemented without breaking any existing compatibility. As far as David's general question(s), I don't claim to 100% understand all the issues but here are my thoughts: When I wrote my SATA drivers for AIX back in 2006 in C++ (using G++), I picked a compiler and stuck with it. I still use the same compiler for that project to this day. I think anyone / everyone will do the same. >From David's description, it sounds like AIX does not really have a design and >did not really address the issues that crop up if (for example) PR 33704 is implemented. The end user just wants something that will work even if the path is long and hard. An easy short path is just a benefit. The long path may include finding open source code for libraries shipped with AIX but I did that anyway so I could debug any problems that came up. I know that everything has a bug or two. I'd rather have a hope of finding an understanding the bug than not. So I used open source or rolled my own for all of the driver code. I lean towards implementing it and make it the default with options to go back to how things were before. It also sounds like if a user switched from VAC to XLC, things would be subtly different. If that is the case, then I would be even more inclined to implement it. Thank you to all who helped. Thank you for gcc... Perry Smith
