Go Back   EQEmulator Home > EQEmulator Forums > Development > Development::Development

Development::Development Forum for development topics and for those interested in EQEMu development. (Not a support forum)

Reply
 
Thread Tools Display Modes
  #1  
Old 10-07-2014, 10:35 AM
CoryWalker
Fire Beetle
 
Join Date: Oct 2014
Posts: 23
Default 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.
Reply With Quote
  #2  
Old 10-07-2014, 04:27 PM
jdoran
Hill Giant
 
Join Date: Jul 2012
Posts: 212
Default

Was that the first error message?

Is there a "#include <string>" in the file?
Reply With Quote
  #3  
Old 10-07-2014, 07:29 PM
KLS
Administrator
 
Join Date: Sep 2006
Posts: 1,348
Default

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

Similar issue?
Reply With Quote
  #4  
Old 10-07-2014, 08:08 PM
CoryWalker
Fire Beetle
 
Join Date: Oct 2014
Posts: 23
Default

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?

Last edited by CoryWalker; 10-07-2014 at 08:10 PM.. Reason: Minor grammar error.
Reply With Quote
  #5  
Old 10-08-2014, 07:21 AM
KLS
Administrator
 
Join Date: Sep 2006
Posts: 1,348
Default

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.
Reply With Quote
  #6  
Old 10-08-2014, 11:18 AM
CoryWalker
Fire Beetle
 
Join Date: Oct 2014
Posts: 23
Default

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);

Last edited by CoryWalker; 10-08-2014 at 05:07 PM.. Reason: Fixed code for variable param_chars.
Reply With Quote
  #7  
Old 10-08-2014, 11:30 AM
CoryWalker
Fire Beetle
 
Join Date: Oct 2014
Posts: 23
Default

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.
Reply With Quote
  #8  
Old 10-09-2014, 05:49 PM
demonstar55
Demi-God
 
Join Date: Apr 2008
Location: MA
Posts: 1,165
Default

What is your libc(++)?
Reply With Quote
  #9  
Old 10-14-2014, 09:59 AM
CoryWalker
Fire Beetle
 
Join Date: Oct 2014
Posts: 23
Default

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!
Reply With Quote
Reply

Tags
clang, freebsd, gcc

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump

   

All times are GMT -4. The time now is 10:42 AM.


 

Everquest is a registered trademark of Daybreak Game Company LLC.
EQEmulator is not associated or affiliated in any way with Daybreak Game Company LLC.
Except where otherwise noted, this site is licensed under a Creative Commons License.
       
Powered by vBulletin®, Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Template by Bluepearl Design and vBulletin Templates - Ver3.3