On Wed, Apr 05, 2017 at 02:35:12AM -0400, al davis wrote: > So the reason for the crash is probably that during exit, it ran the > destructor, then attempted to use the object that has already been > destroyed.
yes. if you switch to "wrong link order" with gcc (for linux/gcc, that is globals.cc at the end), it segfaults all the same. just gcc seems to optimize out the _map=NULL assignment. or something like that. in effect, you cannot "see" it segfaulting with -O2, try -O0. > It's still suspicious because I don't know what std::map does in cases > like this. the real problem seems to be the link order. what is the motivation to reverse the link order (freebsd+clang?) in the first place? shouldn't this break other projects as well? and then: automake+libtool is trying hard to provide a platform independent linking experience. gnucap+autotools does use libtool for that particular step. it would be interesting to know if they provide countermeasures. or the other way round: they might be interested in this sort of linker mis(?)behaviour... cheers felix _______________________________________________ Gnucap-devel mailing list [email protected] https://lists.gnu.org/mailman/listinfo/gnucap-devel
