On Oct 29, 2012, at 9:32 AM, Jonathan Wakely wrote: > On Oct 29, 2012 1:54 PM, "Perry Smith" wrote: >> >> My original logic in adding them to libstdc++.a is they are only used >> (called) by code automatically produced by g++ and not gcc. > > That doesn't make sense. Both gcc and g++ are just driver programs > that invoke the appropriate compiler program, which for C++ is > cc1plus. So C++ code can be compiled by gcc, and doesn't necessarily > link to libstdc++. > > Putting the files in libsupc++ might make sense but libstdc++ is > definitely wrong.
You've mentioned this before. I think you are needlessly splitting hairs. The construct that produces the code that causes the failure is a c++ construct. The construct that causes the compiler to produce a call to atexit is a static of a variable with a non-trivial destructor declared inside a function. This program, does not compile with gcc: > #include <stdio.h> > > class foo { > private: > const char *name; > void mess(const char *s) { > printf("%s %s\n", s, name); > } > > public: > foo(const char *s) { > name = s; > mess("ctor"); > } > > ~foo() { > mess("dtor"); > } > }; > > foo& func() > { > static foo val("func"); > return val; > } But it compiles just fine with g++. For most platforms, the compiler produces a call to __cxa_atexit. On AIX, because AIX does not have __cxa_atexit natively, the compiler produces a call to atexit. atexit doesn't really have the smarts required for shared libraries. I've discussed this all at length before. Perry