After filing bugs for gcc and glibc (on their respective bugzilla's) and finding out that this is not a problem with either of them, I took a look at what exactly the ebuild is doing that would make std::locale(""); not work. I found that the ebuild uses --enable-clocale=generic, so I looked in gcc-3.4.0/libstdc++-v3/config/locale/generic/c_locale.cc at line 148 (the method that is throwing the exception) and found this: void locale::facet::_S_create_c_locale(__c_locale& __cloc, const char* __s, __c_locale) { // Currently, the generic model only supports the "C" locale. // See http://gcc.gnu.org/ml/libstdc++/2003-02/msg00345.html __cloc = NULL; if (strcmp(__s, "C")) __throw_runtime_error(__N("locale::facet::_S_create_c_locale " "name not valid")); } As you can see, the only locale that is valid in the generic model is the "C" locale. This is unacceptable since it breaks localization in any C++ code that uses it (most gtkmm/gnomemm programs use it, for example). I propose that we switch to using --enable-locale=glibc (the glibc code works fine) until we get a use flag for this, since not having locales in c++ code is unacceptable. Reproducible: Always Steps to Reproduce:
Created attachment 31688 [details] Test case This test case compiles fine with gcc-3.4.0 from portage, but when this is run, it will throw an exception because only "C" is accepted in std::locale()'s argument list with --enable-clocale=generic in the configure options of gcc.
i think i would rather let configure decide for itself so that it doesnt interfere with the embedded devs using uclibc. does this work for you when you remove --enable-clocale completely?
That works just fine. I now agree that we should allow configure to handle this.
gcc-3.4.0-r4 should be fixed... re-open this bug if it is not
