Closed GoogleCodeExporter closed 8 years ago
"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
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
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
... and the output of just "locale" too, naturally.
Original comment by Strahinja.Markovic@gmail.com
on 9 Oct 2010 at 10:39
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
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
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:
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
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
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
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
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
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
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
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
Original issue reported on code.google.com by
philant...@gmail.com
on 9 Oct 2010 at 9:59