locale::facet::_S_create_c_locale name not valid

[ghost]

Tried to run the latest stable build and got this error:

[username@computername c10t]$ ./c10t --help terminate called after throwing an instance of 'std::runtime_error' what(): locale::facet::_S_create_c_locale name not valid Keskeytetty

("Keskeytetty") is Finnish for "Interrupted" or something...

All dependencies should be OK.

I tried to run with --debug but it gave the same error, as well as --version.

[uap-universe]

You have already posted that you are using a finnish locale setting, but to have some more information about the settings please issue the command "locale" on your command line and post your result here.

I have no idea why this is happening yet, but I try to compare as many not working and working settings I can find, to figure it out :D

[ghost]

Locale command output here:

$ locale

LANG=fi_FI.UTF-8 LC_CTYPE=fi_FI.UTF-8 LC_NUMERIC=fi_FI.UTF-8 LC_TIME=fi_FI.UTF-8 LC_COLLATE=fi_FI.UTF-8 LC_MONETARY=fi_FI.UTF-8 LC_MESSAGES=fi_FI.UTF-8 LC_PAPER=fi_FI.UTF-8 LC_NAME=fi_FI.UTF-8 LC_ADDRESS=fi_FI.UTF-8 LC_TELEPHONE=fi_FI.UTF-8 LC_MEASUREMENT=fi_FI.UTF-8 LC_IDENTIFICATION=fi_FI.UTF-8 LC_ALL=

[uap-universe]

I tried to set my environment variables to fi_FI.UTF-8 and to reproduce this bug, but on my CentOS c10t works still fine after setting the variables.

Could you please try to set your variables to en_US.UTF-8? Though every variable has the same value it is enough to set LANG=en_US.UTF-8 and LC_ALL=en_US.UTF-8. Please check the settings by typing "locale" again (if locale still prints out fi_FI.UTF-8, try "export LC_ALL").

You can reset the settings to fi_FI.UTF-8 at any time.

[birdie25]

My ./c10t output.

On CentOS 5.5 x86 [honorcraft@mc minecraft]$ ./c10t --help terminate called after throwing an instance of 'std::runtime_error' what(): locale::facet::_S_create_c_locale name not valid Aborted

locale output:

[honorcraft@mc minecraft]$ locale LANG=en_US.UTF-8 LC_CTYPE="en_US.UTF-8" LC_NUMERIC="en_US.UTF-8" LC_TIME="en_US.UTF-8" LC_COLLATE="en_US.UTF-8" LC_MONETARY="en_US.UTF-8" LC_MESSAGES="en_US.UTF-8" LC_PAPER="en_US.UTF-8" LC_NAME="en_US.UTF-8" LC_ADDRESS="en_US.UTF-8" LC_TELEPHONE="en_US.UTF-8" LC_MEASUREMENT="en_US.UTF-8" LC_IDENTIFICATION="en_US.UTF-8" LC_ALL=

[uap-universe]

Uhm.. yeah. That's.. strange :D

So the lib doesn't seem to have any problem in reading and applying the locale settings, but in setting it. Unfortunately I don't see which function throws the exception, but now I think it is "setlocale".

Could you please try out this code to verify my guess?

#include <locale>

void check_locale(const char* locale_name) {
    if( std::setlocale(LC_ALL, locale_name) == NULL )
        printf("setlocale FAILED : %s\n", locale_name);
    else
        printf("setlocale   OK   : %s\n", locale_name);

    try {
        std::locale my_locale(locale_name);
        printf("ctor   OK   : %s\n", locale_name);
    }
    catch(std::exception& e) {
        printf("ctor FAILED : %s : %s\n", locale_name, e.what());
    }
}

int main(void) {
  check_locale("en_US.UTF-8");
  check_locale("fi_FI.UTF-8");
  return 0;
}

[juuri]

Yeah same error here. I think the shell i'm using is using CentOS. Its a finnish server though the locale is en_US.

Heres my output:

$ ./c10t --version

terminate called after throwing an instance of 'std::runtime_error' what(): locale::facet::_S_create_c_locale name not valid Aborted

$ locale

LANG=en_US.UTF-8 LC_CTYPE="en_US.UTF-8" LC_NUMERIC="en_US.UTF-8" LC_TIME="en_US.UTF-8" LC_COLLATE="en_US.UTF-8" LC_MONETARY="en_US.UTF-8" LC_MESSAGES="en_US.UTF-8" LC_PAPER="en_US.UTF-8" LC_NAME="en_US.UTF-8" LC_ADDRESS="en_US.UTF-8" LC_TELEPHONE="en_US.UTF-8" LC_MEASUREMENT="en_US.UTF-8" LC_IDENTIFICATION="en_US.UTF-8" LC_ALL=

And that code snippet outputs:

setlocale OK : en_US.UTF-8 ctor OK : en_US.UTF-8 setlocale OK : fi_FI.UTF-8 ctor OK : fi_FI.UTF-8

its an annoying problem because our whole server has to look lots of black blocks in the map :P Thanks for using time to solve this!

[uap-universe]

Thanks for using time to solve this!

That's why we are here ;)

Which version of libboost are you using? I'm using 1.46.1 on my CentOS x64 and udoprog recommends 1.47.

If you encounter problems in building 1.47, use 1.46 ;) It's not fun building libboost and it takes some time, but it could solve the problem.

[juuri]

Uhmm.. how do i check the libboost version..?

Unfortunately building libraries is a bit over my tiny linux expertise and i can do only some simple things at the shell :(

Are there any other debug code snippets or ideas how to test the bug?

[uap-universe]

Try:

ls /usr/lib/ | grep boost_system

There should be a *.so containing the verison number. On 64 bit systems you may also try

ls /usr/lib64/ | grep boost_system

The documentation for building and using libboost is located here. But I want to write down the necessary parts to get c10t running into the README file anyway. I just had not the time yet to nuke my libboost away and replace it by a newer versio, so I can precisely note every step.

[Parsiuk]

In CentOS5.6 there is nothing called "boost" in /usr/lib, /lib or /var/lib. If I check a list of packages I can see: "boost.i386 1.33.1-10.el5_7.3". Not sure if that's the same thing..

I'll try to build libboost from sources. Will see how this will go.

And god save me from installing CentOS again. Ever. I should force my VPS provider to install Slackware.

[uap-universe]

Maybe your package manager put the files into /usr/local/lib. Yes it is the same thing, but i'm not sure if this is the runtime only (dunno if the package name was something like boost-dev). Building the lib from source is a very good idea.

If you encounter troubles I'm glad to announce, that (finally) I will find some time tomorrow to write the installation steps to the README. Hopefully they will help then.

[uap-universe]

Renamed this issue and closed the duplicate. Do we have some first results related to the different boost versions?

I upgraded my boost to 1.48 (the newest version) from 1.46 and everything still works fine for me.

[Parsiuk]

Same error after installing boost_1_48_0 from sources.

Does this error actually comes from boost lib?

Edit: and yes, I could "do it wrong". I assumed that once I did ./b2 install and after that ldconfig I'm good to go. Edit2: Works no problem under Slackware (64bit) with boost 1.45.

[uap-universe]

Thought it's related to this bug. But if it still does not work with boost 1.48.... hm... Did you install it into /usr or /usr/local? I don't know if -L is set to search in /usr/local by the Makefiles.

Maybe you installed 1.48 in /usr/local and there is still your old 1.33 in /usr and therefore nothing changed.

If you installed libboost with ./bootstraph.sh without options, please try again using

./bootstrap.sh --prefix=/usr

Maybe this helps.

[Parsiuk]

I remember removing boost package. The library is installed in /usr/local/lib/. I hope I don't have to re-run the whole compilation again. It was a little bit of a nightmare. :) I'll try this tonight. Thank you for info.

[uap-universe]

You should rerun it in my opinion. I have not found any good reason why installing something into /usr/local should be useful :D

If you want the things to stay in /usr/local please read this document and set the environment variables before building c10t.

[juuri]

Yeah its definitely that boost bug. After setting LC_ALL="C" temporarily, new versions of c10t work flawlessly.

Looks like newest official build of boost for CentOS is 1.38 and i unfortunately cant build a new one by myself. At least I have a workaround while waiting for a official build.

[DjDCH]

I have currently the same issue. I'm trying to run c10t on my home server, but it failed as describe here. It's a Debian box, version 5 (lenny), with x86 kernel. Here's the commands output:

$ ./c10t -v
terminate called after throwing an instance of 'std::runtime_error'
  what():  locale::facet::_S_create_c_locale name not valid
Aborted

$ locale
LANG=en_CA.UTF-8
LANGUAGE=en_CA:en
LC_CTYPE="en_CA.UTF-8"
LC_NUMERIC="en_CA.UTF-8"
LC_TIME="en_CA.UTF-8"
LC_COLLATE="en_CA.UTF-8"
LC_MONETARY="en_CA.UTF-8"
LC_MESSAGES="en_CA.UTF-8"
LC_PAPER="en_CA.UTF-8"
LC_NAME="en_CA.UTF-8"
LC_ADDRESS="en_CA.UTF-8"
LC_TELEPHONE="en_CA.UTF-8"
LC_MEASUREMENT="en_CA.UTF-8"
LC_IDENTIFICATION="en_CA.UTF-8"
LC_ALL=

But if I do the following, it's working:

$ LC_ALL="C"
$ export LC_ALL

$ ./c10t -v
c10t - a cartography tool for minecraft
version: git 240c08c, built on Apr  4 2012
by: Udoprog <johnjohn.tedro@gmail.com> et. al (see README)
site: http://github.com/udoprog/c10t

I can successfully run the x86_64 version on an other sever.

[kyred808]

I had this exact same problem with c10t. I am running Ubuntu Server 64-bit v12.04.

I can verify that exporting LC_ALL="C" fixed the issue for me. Thanks =D

[Ben0mega]

If this is a library issue, then running ldd on the the binary will tell show the dynamic libraries it is linking against (and may show the errors). Be sure to run ldd and not ld

[Liz4v]

This affected me in the strangest way, but I found a workaround I'm running c10t in a server with Ubuntu 12.04.1 LTS (precise), my work computer is Ubuntu 12.10 (quantal) and my home computer is a Mac OS X 10.7.5 (lion? i can't recall). If I SSH into my server from my work computer, it worked. If I SSH into my server from my home computer, it didn't.

So today I went into the server's sshd_config file, commented out the line about AcceptEnv, and restarted the SSH daemon.

My Mac OS X: ekevoo@Anas:~$ locale LANG= LC_COLLATE="C" LC_CTYPE="UTF-8" LC_MESSAGES="C" LC_MONETARY="C" LC_NUMERIC="C" LC_TIME="C" LC_ALL=

My server before the change: minecraft@puertoprincesa:~$ locale locale: Cannot set LC_CTYPE to default locale: No such file or directory locale: Cannot set LC_ALL to default locale: No such file or directory LANG=en_US.UTF-8 LANGUAGE=en_US:en LC_CTYPE=UTF-8 LC_NUMERIC="en_US.UTF-8" LC_TIME="en_US.UTF-8" LC_COLLATE="en_US.UTF-8" LC_MONETARY="en_US.UTF-8" LC_MESSAGES="en_US.UTF-8" LC_PAPER="en_US.UTF-8" LC_NAME="en_US.UTF-8" LC_ADDRESS="en_US.UTF-8" LC_TELEPHONE="en_US.UTF-8" LC_MEASUREMENT="en_US.UTF-8" LC_IDENTIFICATION="en_US.UTF-8" LC_ALL=

My server after the change: minecraft@puertoprincesa:~$ locale LANG=en_US.UTF-8 LANGUAGE=en_US:en LC_CTYPE="en_US.UTF-8" LC_NUMERIC="en_US.UTF-8" LC_TIME="en_US.UTF-8" LC_COLLATE="en_US.UTF-8" LC_MONETARY="en_US.UTF-8" LC_MESSAGES="en_US.UTF-8" LC_PAPER="en_US.UTF-8" LC_NAME="en_US.UTF-8" LC_ADDRESS="en_US.UTF-8" LC_TELEPHONE="en_US.UTF-8" LC_MEASUREMENT="en_US.UTF-8" LC_IDENTIFICATION="en_US.UTF-8" LC_ALL=

It's not the first time I've run into locale trouble with servers that were solved this way. I'm starting to conclude this is a bad default configuration for ssh-server.

[reiz]

I have the same issue. I just can't execute mongodump :-(

[GoldAndLink]

I resolved this problem with: locale-gen en_US.UTF-8 on ubuntu 10.04

[snailshen2014]

I hava the same issue on debian

[evildeeds]

This appears to be a five years old upstream bug with libboost, either update your system or try one of the suggested workarounds and if thats not the problem then open a new bug.

As suggested in this issue you may wish to ensure that; Your system is updated. LC_* envs are correctly set. System is configured to use unicode and UTF-8. Selected locale actually exists or (re-)create english locale by running 'locale-gen en_US.UTF-8'.

Since this is not actually c10t's fault, other then that libboost is used, I'm locking this to prevent futher necroing.