Re: c++ regression in trunk

[howarth at bromo dot msbb dot uc dot edu (Jack Howarth)]

Mike,
   I've checked all of the object files in xplor-nih with...

nm -m *.o | c++filt | grep info | grep -v external

...and I get no hits suggesting it can't be a wrong visibility problem.
Is there some approach I can use to figure out if it is a throw across
a dylib or bundle boundary? My initial guess is that it isn't that either.
The .cc source files that show up in the backtrace (dinternal.cc,
dint-xplor.cc and dint-powell.cc) are all linked together into
libintVar.dylib using...

g++-4 -dynamiclib -flat_namespace -undefined suppress -single_module dinternal.o dint-atom.o dint-node.o dint-loop.o dint-step.o dint-powell.o dint-conmin.o dint-simplex.o dint-pc6.o dint-xplor.o publicIVM.o -o libintVar.dylib    -lcrypto /System/Library/Frameworks/vecLib.framework/Versions/A/vecLib 

Also, I don't see this c++ regression when building xplor-nih with
the gcc/g++ from Xcode 2.3 and gfortran from gcc trunk or with
gcc/g++/gfortran from gcc 4.1.1. If it really were a problem with
a throw across a dylib wouldn't those versions break as well?
    I noticed from the 4.2 change page that...

The configure variable enable-__cxa_atexit is now enabled by default for more targets. Enabling this variable is necessary in order for static destructors to be executed in the correct order, but it depends upon the presence of a non-standard C library in the target library in order to work. The variable is now enabled for more targets which are known to have suitable C libraries.

Is darwin one of those targets that changed at 4.2? If so is there a flag
to reverse that behavior for individual source files?
              Jack