fc_tests and flightcrew-gui throw exception during startup

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Compile from source against Qt-4.6.3.
2. Start fc_tests or flightcrew-gui.
3. See it fail.

What is the expected output? What do you see instead?
Tests running / GUI.

/usr/bin/flightcrew-gui
terminate called after throwing an instance of 'std::runtime_error'
  what():  locale::facet::_S_create_c_locale name not valid
zsh: abort      /usr/bin/flightcrew-gui

What version of the product are you using? On what operating system?
0.7.0, built from source on Linux.

Original issue reported on code.google.com by philant...@gmail.com on 9 Oct 2010 at 9:59

[GoogleCodeExporter]

"On Linux" is a bit vague. On my Ubuntu 10.04 x64, Ubuntu 8.04 x64 and Ubuntu 
8.04 x86 it builds and runs just fine.

Original comment by Strahinja.Markovic@gmail.com on 9 Oct 2010 at 10:16

[GoogleCodeExporter]

Are you perhaps running SUSE? FC uses boost::filesystem, so this seems to be 
related:
https://svn.boost.org/trac/boost/ticket/4688

If this is indeed the case, then it's a boost bug.

Original comment by Strahinja.Markovic@gmail.com on 9 Oct 2010 at 10:34

[GoogleCodeExporter]

Also, please provide the output of running "locale -a" on your system.

Original comment by Strahinja.Markovic@gmail.com on 9 Oct 2010 at 10:37

[GoogleCodeExporter]

... and the output of just "locale" too, naturally.

Original comment by Strahinja.Markovic@gmail.com on 9 Oct 2010 at 10:39

[GoogleCodeExporter]

I'm on Exherbo Linux, a source-based distro, for which I'm packaging FlightCrew 
(and Sigil).

locale -a:
C
de_DE.utf8
en_GB.utf8
en_US.utf8
POSIX

locale
LANG=en_GB.utf8
LC_CTYPE=de_DE.utf8
LC_NUMERIC=de_DE.utf8
LC_TIME=de_DE.utf8
LC_COLLATE=de_DE.utf8
LC_MONETARY=de_DE.utf8
LC_MESSAGES=en_US.utf8
LC_PAPER=de_DE.utf8
LC_NAME=de_DE.utf8
LC_ADDRESS=de_DE.utf8
LC_TELEPHONE=de_DE.utf8
LC_MEASUREMENT=de_DE.utf8
LC_IDENTIFICATION=de_DE.utf8
LC_ALL=

The boost version is 1.43.0 but, interestingly, I don't see flightcrew-cli 
linking against boost at all.

Original comment by philant...@gmail.com on 9 Oct 2010 at 10:48

[GoogleCodeExporter]

flightcrew-cli links statically against flightcrew, and that links statically 
against BoostParts, which is extracted from boost 1.44. Transitively, 
flightcrew-cli uses boost.

Well this seems to be either somehow related to your system or boost itself. 
Either way, I doubt there's anything I can do. I have FC compiling, passing the 
tests and running on like 7 different OS's, three of them flavors of Linux and 
one flavor of Unix (Snow Leopard).

As such, I'll be closing this issue. Really sorry. If you find any more 
information, feel free to add it to the issue.

Original comment by Strahinja.Markovic@gmail.com on 9 Oct 2010 at 11:02

• Changed state: WorksForMe

[GoogleCodeExporter]

Yes, it is this bug: https://svn.boost.org/trac/boost/ticket/4688

And it's included in your bundled BoostParts directory - which is one reason 
why bundling is such a bad idea. Really, you're just trading a few users' pain 
(those few who will compile from source on Windows/MacOS) against the pain of 
every packager and any user who needs or wants to compile on Linux. Which is a 
way more likely and frequent scenario.

Nevertheless, attached you'll find a patch (against 0.7.0) for your BoostParts 
bundle.

Original comment by philant...@gmail.com on 10 Oct 2010 at 12:24

Attachments:

• FlightCrew-0.7.0-boost_filesystem_locale.patch

[GoogleCodeExporter]

I've seen that patch, and I'm pretty sure it's not right. It replaces the 
creation of the locale-specific native environment (see the comment above the 
line) with an empty locale. That changes functionality.

Also, I think this may be a libstdc++ problem. I appears to be a common problem:
http://stackoverflow.com/questions/2928409/boostfilesystempathstdwstring-throw-e
xception
http://archives.free.net.ph/message/20080125.121049.0b2f25ea.de.html

And this one in particular:
http://stackoverflow.com/questions/1745045/stdlocale-breakage-on-macos-10-6-with
-langenus-utf-8

Try to compile and run this program on your machine:
#include <locale>

int main ( int argc, char *argv [] ) {
    std::locale::global(std::locale(""));
    return 0;
}

If it throws an exception, then the problem is not with boost, but with the 
system or libstdc++.

Original comment by Strahinja.Markovic@gmail.com on 10 Oct 2010 at 10:18

[GoogleCodeExporter]

And "" as an argument to std::locale("") is valid and has to be supported as 
per the c++ spec.

"explicit locale(const char* std_name );
Effects: Constructs a locale using standard C locale names, e.g. "POSIX".
The resulting locale implements semantics defined to be associated with that
name.
Throws: runtime_error if the argument is not valid, or is null.
Remarks: The set of valid string argument values is "C", "", and any
implementation-defined values."

Original comment by Strahinja.Markovic@gmail.com on 10 Oct 2010 at 10:26

[GoogleCodeExporter]

Ok, the testcase from comment 8 works fine if I set LC_ALL=C but throws the 
exception with LC_ALL=en_GB.utf8. That locale is valid and works otherwise, 
though.

Original comment by philant...@gmail.com on 10 Oct 2010 at 10:37

[GoogleCodeExporter]

I'm implementing a workaround that I'll want you to test out. Please hold.

Original comment by Strahinja.Markovic@gmail.com on 10 Oct 2010 at 10:40

[GoogleCodeExporter]

Ok, here's a personal clone I made of the repo to fix this problem.
http://code.google.com/r/strahinjamarkovic-boost-locale/

In the future, if you wish to submit patches, make personal clones, not 
patches. It's the 21st century. :)

I would like to note that on ubuntu, that program from comment 8 runs just 
fine. It doesn't work on Mac because they have a broken libstdc++. Fix yours 
for exherbo, this will bite your users and it is a problem with the system.

Try to compile the clone and run the tests, but I'm still not sure whether to 
include this in the main repo. It is clearly a problem with your OS, 
std::locale("") *has* to work, and does so on other Linux distros.

Original comment by Strahinja.Markovic@gmail.com on 10 Oct 2010 at 11:09

[GoogleCodeExporter]

Oh, and it works on Ubuntu regardless of the locale set. I tried en_US.utf8, 
and C and it works just as well. I have another computer which has the Croatian 
locale, and it works there too.

Original comment by Strahinja.Markovic@gmail.com on 10 Oct 2010 at 11:16

[GoogleCodeExporter]

Yes, it's the 21st century and you're still using Mercurial (instead of 
something sane like git)! ;)

As for this issue - it turned out to be a simple configuration problem in 
gcc-4.5.1: If I'm reading the code correctly, --enable-clocale=gnu should be 
the default on Linux and we relied on that. It doesn't work, though, and 
instead a non-GNU approach is used by default. That makes std::locale("") fail.

Your workaround did the job, too.

Thanks for your help and sorry for the noise - but at least I've made sure now 
this won't happen to anyone else using Exherbo. :)

Original comment by philant...@gmail.com on 10 Oct 2010 at 1:44

[GoogleCodeExporter]

Git vs. Hg is a religious war, and I'm squarely on the Hg side. And I've used 
both extensively. :)

Glad you got the problem fixed on your end.

Original comment by Strahinja.Markovic@gmail.com on 10 Oct 2010 at 1:48