Re: [Boost-bugs] [Boost C++ Libraries] #5928: FileSystem runtime error: locale::facet::_S_create_c_locale name not valid

Subject: Re: [Boost-bugs] [Boost C++ Libraries] #5928: FileSystem runtime error: locale::facet::_S_create_c_locale name not valid
From: Boost C++ Libraries (noreply_at_[hidden])
Date: 2012-02-06 07:06:27


#5928: FileSystem runtime error: locale::facet::_S_create_c_locale name not valid
-------------------------------+--------------------------------------------
  Reporter: anonymous | Owner: bemandawes
      Type: Bugs | Status: new
 Milestone: To Be Determined | Component: filesystem
   Version: Boost 1.47.0 | Severity: Showstopper
Resolution: | Keywords:
-------------------------------+--------------------------------------------

Comment (by Nickolay Cherney <koliasvskj@…>):

 Replying to [comment:4 midnight-runner@…]:
> Replying to [comment:3 bemandawes]:
> > Replying to [comment:2 midnight-runner@…]:
> > > Update:
> > > Oh I just realized i used the wrong machine to do the interactive
 test ...
> > > and now it turns out that the programs fails in the interactive
 sessions as well, as long LC_ALL isn't set to 'C'.
> > >
> > >
> > > System:
> > > Linux mphy-s01 2.6.31-21-generic #59-Ubuntu SMP Wed Mar 24 07:28:27
 UTC 2010 x86_64 GNU/Linux
> >
> > I'm going to need a little test program that demonstrates this
 problem. My tests here all work perfectly, running fine if the environment
 is valid, otherwise throwing an exception after main() has started. So it
 would be very helpful to see your code that is failing, and be able to
 test with it here.
> >
> > Thanks,
> >
> > --Beman
> Ok I have prepared a few test cases with two different systems
 (different compilers).
> First of all, the problem occurs only if the programs are linked
 statically and only if codesample 1 is used. Codesample 2 works fine.
>
> System 1 (Ubuntu 11.10):
> Linux XXX 3.0.0-15-server #25-Ubuntu SMP Mon Jan 2 19:14:55 UTC 2012
 x86_64 x86_64 x86_64 GNU/Linux
> gcc version 4.6.1 (Ubuntu/Linaro 4.6.1-9ubuntu3)
>
> System 2 (Ubuntu 09.10):
> Linux XXX 2.6.31-21-generic #59-Ubuntu SMP Wed Mar 24 07:28:27 UTC 2010
 x86_64 GNU/Linux
> gcc version 4.4.1 (Ubuntu 4.4.1-4ubuntu9)
>
> Boost with version 1.48 was employed and both systems use the same boost
 includes and libs (via nfs shares).
>
> Codesample 1 (won't work if compiled statically with system 1 and
 running on system 2 with "incorrec LC-ALL"):
>
> {{{
> #include <boost/filesystem.hpp>
>
> int main ( int argc, char *argv[] ) {
> boost::filesystem::path path;
> std::string filename("readme.txt");
> path = filename; // this isn't working
> // path = "readme.txt"; // this isn't working
> std::cout << "OK" << std::endl;
> return 0;
> }
> }}}
>
>
> Codesample 2 (works all the time):
>
> {{{
> #include <boost/filesystem.hpp>
>
> int main ( int argc, char *argv[] ) {
> boost::filesystem::path path("readme.txt");
> std::cout << "OK" << std::endl;
> return 0;
> }
> }}}
>
>
> Compiling codesample 1 with system 1:[[BR]]
> g++ main.cpp -o test_SYS-1_dyn -L$LIB_PATH -lboost_system
 -lboost_filesystem -I$INCLUDE_PATH[[BR]]
> g++ main.cpp -o test_SYS-1_sta -L$LIB_PATH -lboost_system
 -lboost_filesystem -I$INCLUDE_PATH -static
>
> Compiling codesample 1 with system 2:[[BR]]
> g++ main.cpp -o test_SYS-2_dyn -L$LIB_PATH -lboost_system
 -lboost_filesystem -I$INCLUDE_PATH[[BR]]
> g++ main.cpp -o test_SYS-2_sta -L$LIB_PATH -lboost_system
 -lboost_filesystem -I$INCLUDE_PATH -static
>
> Running the programs:
>
> With system 1: [[BR]]
> and export LC-ALL='C': [[BR]]
> test_SYS-1_dyn:OK [[BR]]
> test_SYS-1_sta:OK [[BR]]
> test_SYS-2_dyn:OK [[BR]]
> test_SYS-2_sta:OK [[BR]]
>
> and export LC-ALL='en_GB.UTF-8': [[BR]]
> test_SYS-1_dyn:OK [[BR]]
> test_SYS-1_sta:OK [[BR]]
> test_SYS-2_dyn:OK [[BR]]
> test_SYS-2_sta:OK [[BR]]
>
>
> With system 2: [[BR]]
> and export LC-ALL='C': [[BR]]
> test_SYS-1_dyn:OK [[BR]]
> test_SYS-1_sta:OK [[BR]]
> test_SYS-2_dyn:OK [[BR]]
> test_SYS-2_sta:OK [[BR]]
>
> and export LC-ALL='en_GB.UTF-8': [[BR]]
> test_SYS-1_dyn:OK [[BR]]
> test_SYS-1_sta:
> terminate called after throwing an instance of 'std::runtime_error'
> what(): locale::facet::_S_create_c_locale name not valid
> Aborted
> test_SYS-2_dyn:OK [[BR]]
> test_SYS-2_sta:OK [[BR]]
>
>
> Thanks,
>
> Christian
 I experienced similar problem when I linked statically to boost and
 runtime libraries; but the reason was not a Boost.

 AFAIK the line [[BR]]
 {{{path = filename; // this isn't working}}} [[BR]]
 internally calls to some STL's functions. One of them eventually calls to
 codecvt() constructor which in turn calls to the {{{newlocale(...)}}}
 function from glibc and throws the {{{locale::facet::_S_create_c_locale}}}
 exception if newlocale() fails (i.e. returns 0).

 The system where I built the application is Slackware 13.37 (like System 1
 in your case) with glibc-2.13. But the system where the application was
 intended to run is Slackware 12.0 (System 2) with glibc-2.7

 Trying to strace the application on System 2 shows that (as a result of a
 call to newlocale()) statically linked glibc-2.13 opens
 /usr/lib/locale/ru_RU.koi8r/LC_CTYPE file (I guess it would be
 /usr/lib/locale/en_GB.utf8/LC_CTYPE in your testcase) it stumbles upon
 incompatible version of this file (from glibc-2.7).

 Exact file which is opened by call to glibc's newlocale() depends on
 LC_ALL (or LANG if no LC_ALL set) environment variable; but if LC_ALL/LANG
 is set to standard intrinsic locale (e.g. LC_ALL=C or LC_ALL=POSIX) then
 glibc-2.13 constructs the locale without opening any file, so the
 newlocale() call is successful in this case. If one manages to link
 application to runtime libraries dynamically (regretfully this is not my
 case) then the call to newlocale() would be successful too.

 Hope this helps. Good luck.

-- 
Ticket URL: <https://svn.boost.org/trac/boost/ticket/5928#comment:5>
Boost C++ Libraries <http://www.boost.org/>
Boost provides free peer-reviewed portable C++ source libraries.

This archive was generated by hypermail 2.1.7 : 2017-02-16 18:50:08 UTC