------- Comment #11 from pcarlini at suse dot de 2007-03-15 01:11 ------- (In reply to comment #10) > The problem is that the library is not be ing properly compiled for > multi-threaded use, but that by some luck basic_file.cc happened to be > compiled > that way anyway. c++locale.cc was not so lucky.
Sorry, usually we don't believe in shear lock. I mean, we would like to understand what really happened before changing things. More below... > The solution I believe is best is to compile with the -pthread option. This is > what GNU's own documentation recommends for building MT-compatible objects, > and > is designed to be supported across all platforms. Note that GNU-proper systems are already ok, whereas for other systems, like solaris, the right switch seems -pthreads, per a comment in our thread testcases, for example. I'm afraid that different switches are used on yet different systems... Then, we should analyze in details what happens when that switch is in effect, whether for example additional libraries are linked in and we really want that. > The next best solution is to add > > #include <bits/c++config.h> > #include <clocale> Honestly, I don't think that makes sense. Did you *really* test it? Because, as far as I can see, the cc file at issue includes the whole <locale>, which, in turn, includes <bits/c++locale.h>, which is a link to config/locale/generic/c_locale.h in the sources, which includes <clocale> anyway. All in all, there are still too many things I don't understand clearly... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31117
