Compiling EQEMu with gcc49 fails on FreeBSD 10.0 x64
 

I'm getting compilation errors on FreeBSD 10.0 x64 using both gcc49 and clang with flag -std=c++11.

The problem is in the following file:

/usr/local/build/eqemu/common/debug.cpp:369:23

Here is the full error:

--
/usr/local/build/eqemu/common/debug.cpp: In member function 'bool EQEMuLog::Dump(EQEMuLog::LogIDs, uint8*, uint32, uint32, uint32)':
/usr/local/build/eqemu/common/debug.cpp:369:23: error: 'to_string' is not a member of 'std'
asciiOutput.append(std::to_string((long long)data[indexInData]));
--

The top of this file has the necessary includes that would normally place this function into the correct "std" namespace - so I wonder what is going on here?

Please let me know if you need any additional information.

Was that the first error message?

Is there a "#include <string>" in the file?

http://lists.freebsd.org/pipermail/f...il/091912.html

Similar issue?

jdoran - Yes - that was the first and only error message for that file. That specific line in debug.cpp doesn't appear that important. After commenting it out I found that several other files are affected in exactly the same way. There are many files that use the std::to_string function.

KLS - Yes - I believe you have pinpointed the exact problem. This will not compile because of that _GLIBCXX_USE_C99 issue.

The exact version of gcc I'm using is 4.9.1 and as you've pointed out in the link this also explains why clang won't work either - this is a FreeBSD specific issue.

I suppose this is a good time to ask the following question. What are this project's portability goals?

We strive to support as many platforms as we can but obviously standard libraries that don't include everything due to bugs in a platform are... problematic.

Think we could add the flag to CMake for FreeBSD to get past that? I don't have a FreeBSD setup to try.

C++11 is still young as an ISO standard. I'm sure all platforms will catch up in a few years.

If you look in debug.cpp, line 369 you will notice that there is a little bit of casting going on to a "long long" because VS 2010 didn't have the standard fully implemented either at the time of writing. I think an opportunity exists to make the code cleaner and more portable with a single refactoring.

It seems kind of silly that the problem of converting an integer to a string is a problem with modern day development systems. Still, here is what I would propose.

Create a set of static, overloaded methods:

static string ConvertToString (int param);
static string ConvertToString (long long param);

The following function body converts an integer to a string using the Standard C Library:

char param_chars[16];
sprintf(param_chars, "%d", param);
std::string paramString (param_chars);
return paramString;

You will immediately notice that I have little experience with C++. However, I believe this will compile and run anywhere and we don't have to do any casting at all.

Later on - when C++11 is fully implemented everywhere - we can replace it with:

return std::to_string(param);

KLS - to answer your actual question - we most certainly could add a flag for FreeBSD in the cmake files. However, I believe this would make both the source code and the build system slightly more complex.

I almost always favor the strategy of getting the source code to be able to be compiled without adding switches to the build system and minimizing the number of conditional preprocessor directives - unless there is some huge benefit to doing otherwise.

What is your libc(++)?

Hey demonstar55 - thank you for your response.

I'm not quite sure what you are looking for with respect to the libraries you are asking about. Are you looking for version or location information?

As specified before I'm using GCC 4.9.1. Please let me know!