Nagilum wrote:FreeBSD now has boost1.55 which I believe is the root cause for this problem.
Unfortunately don't really know how to work around this.
That boost code looks like it should be fine, and that portion at least looks like it has has been around since boost 1.45. The comment preceding it says
//! A function to replace the std::transform( , , ,tolower) construct
/*! This function simply takes a string, and changes all the characters
* in that string to lowercase (according to the default system locale).
* In the event that a compiler does not support locales, the old
* C style tolower() is used.
*/
which suggests that perhaps the problem is that your boost was compiled with the BOOST_DATE_TIME_NO_LOCALE flag not defined so it is trying to use the tolower version with locale, but perhaps your current compiler is not supporting locales, or perhaps you simply don't have a locale set?
If I provided any code, scripts or other content here, it's released under GPL 2.0 and CC-BY-SA 3.0
hmm, I'm not sure if this would cause other problems, but if you built boost with BOOST_DATE_TIME_NO_LOCALE defined, then boost would use the simpler version of std::tolower that doesn't have a locale. Doesn't really seem like a good solution, but might get FO to compile in that environment.
If I provided any code, scripts or other content here, it's released under GPL 2.0 and CC-BY-SA 3.0
#if defined(FREEORION_LINUX) || defined(FREEORION_FREEBSD)
int main(int argc, char* argv[]) {
// copy command line arguments to vector
std::vector<std::string> args;
for (int i = 0; i < argc; ++i)
args.push_back(argv[i]);
// set options from command line or config.xml, or generate config.xml
if (mainConfigOptionsSetup(args) != 0) {
std::cerr << "main() failed config." << std::endl;
return 1;
}
#endif
Obviously this is far from ideal since the jail to be running and xhost + opens up X to any conections.
But at least it works. Now we have to figure out a way to make this work in a more standard manner.
The best solution would still be if we were able to compile FO with clang.
Nagilum wrote:The best solution would still be if we were able to compile FO with clang.
That's an easy one: just fix the places where clang complains about. :o)
But seriously: I can't reproduce the issue about operator== and operator!= you reported on fedora with clang 3.3. But I get compile errors when the compile reaches the ASL stuff inside the parser project.
Resident code gremlin
Attached patches are released under GPL 2.0 or later.
Git author: Marcel Metz
adrian_broher wrote:But seriously: I can reproduce the issue about operator== and operator!= you reported on fedora with clang 3.3. But I get compile errors when the compile reaches the ASL stuff inside the parser project.
This is going to be an issue on OSX too... once I move to a recent version of Xcode (which I'll have to do once I upgrade to Mavericks AFAIK, and I won't be able to postpone that forever), I'll also have to use clang, as gcc support is dropped in Xcode4+.
Nagilum wrote:The best solution would still be if we were able to compile FO with clang.
That's an easy one: just fix the places where clang complains about. )
I have no clue about serious C++ I'm afraid. If it was Perl I would use Data::Dump(er) to dump the structure and everything would be plain to see or test.. :-/
adrian_broher wrote:But seriously: I can't reproduce the issue about operator== and operator!= you reported on fedora with clang 3.3. But I get compile errors when the compile reaches the ASL stuff inside the parser project.
That is indeed weird and I currently have no idea what the root cause could be since I get the same error with clang3.4 from ports (in case the base clang had some unusual patches..).