Hi, I am currently battling a buggy locale implementation (or lack thereof) in GCC on Solaris, which is affecting my use of boost::filesystem. Please have a look at the following thread for more information regarding this: http://gcc.gnu.org/ml/gcc-help/2009-09/msg00212.html In short, Solaris/GCC has a huge limitation that it does not support locales besides "C" or "POSIX". I talked to the GCC folks regarding this issue, and they said that at ONE time, GCC implemented the locale support for Solaris, but over time, the code was not maintained and therefore died :( This is very unfortunate because after looking through the boost filesystem code (boost/libs/filesystem/src/path.cpp), I found out that it creates a default locale by invoking std::locale("") (boost/libs/filesystem/src/path.cpp @ line 911) . Therefore, if my client sets the locale to anything but "C" or "POSIX", when it tries to create the default locale object via std::locale(""), it throws a runtime exception which crashes my program. So, my question is whether anyone knows of a work-around for this? I came up with one idea, but it seems very hackish. I can try to construct a boost::filesystem::path object and try to catch the exception thrown by std::locale(""). If the exception is thrown, I can set the environment variable to "C" or "POSIX" and continue with the program. My other idea is to manually patch boost::filesystem::path to use the following code to create the default locale. (again line 911 in path.hpp) try { use std::locale("") as the default locale; } catch ( std::runtime_error& ) { // We were unable to construct a locale, now use the global locale. use std::locale() as the default locale; } using std::locale() as the default will *always* succeed since it will just use whatever the current global locale is. My concern with this, is that I'll have to manually patch boost for this. Thanks, J