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
