------- Additional Comments From jakub at gcc dot gnu dot org 2005-09-09 08:26 ------- Without init_priority, how can you be sure that other libstdc++.so destructors will not be run after __gnu_internal::freelist is destructed? If there are some destructors and they use the mt allocator (whether to allocate some temporary memory or more likely to free some memory), won't it cause big problems?
As for the lock being static, mt-allocator.cc is the only user of that lock, so I don't see why it should be externally visible, even if just in libstdc++.a (in libstdc++.so symbol versioning will hide it). If there are other locks used solely in one .cc file, I think they should be made static too. Thanks for writing the testcase. Haven't tried to compile your latest patch yet, do the <ext/mt_allocator.h> changes preserve ABI compatibility? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22309
