Building server on Mac OS X
Moderator: Community Managers
Building server on Mac OS X
Has anyone been able to build the server on Mac OS X?
I'm having problems which I think is compatibility issues with pthread, but I'm not entirely sure.
I'm having problems which I think is compatibility issues with pthread, but I'm not entirely sure.
- John Adams
- Retired
- Posts: 4581
- Joined: Wed Aug 28, 2013 9:40 am
- Location: Phoenix, AZ.
- Contact:
Re: Building server on Mac OS X
It's just Debian Linux, isn't it? Check the g++ --version. Has to be 4.8+
Re: Building server on Mac OS X
Not quite. Mac OS X is based on NeXtStep.
The problem is PTHREAD_MUTEX_RECURSIVE_NP which is not defined on Mac. I replaced it with PTHREAD_MUTEX_RECURSIVE to get it to compile, but I'm not sure if it will work or not. Will test it as soon as I get the socket stuff to compile with clang.
The problem is PTHREAD_MUTEX_RECURSIVE_NP which is not defined on Mac. I replaced it with PTHREAD_MUTEX_RECURSIVE to get it to compile, but I'm not sure if it will work or not. Will test it as soon as I get the socket stuff to compile with clang.
Re: Building server on Mac OS X
[quote="Kandra"]Not quite. Mac OS X is based on NeXtStep.
The problem is PTHREAD_MUTEX_RECURSIVE_NP which is not defined on Mac. I replaced it with PTHREAD_MUTEX_RECURSIVE to get it to compile, but I'm not sure if it will work or not. Will test it as soon as I get the socket stuff to compile with clang.[/quote]
Let me know if you get it compiling and I'll put a patch together for it.
The problem is PTHREAD_MUTEX_RECURSIVE_NP which is not defined on Mac. I replaced it with PTHREAD_MUTEX_RECURSIVE to get it to compile, but I'm not sure if it will work or not. Will test it as soon as I get the socket stuff to compile with clang.[/quote]
Let me know if you get it compiling and I'll put a patch together for it.
Re: Building server on Mac OS X
It compiles without errors now but it doesn't load the mysqlconnector library as it should when starting the server. Probably an error in my cmake build definition.
Problems with both clang and gcc-4.8 on Mavericks:
- PTHREAD_MUTEX_RECURSIVE_NP is not defined
- <linux/limits.h> should be <limits.h>
Problems with clang (probably independent of operating system):
- "using namespace std;" can cause problems... in this case it's bind() in Socket.cpp. Replace with ::bind()
I will clean things up tomorrow and try to fix the mysqlconnector, but right now I need some sleep.
Problems with both clang and gcc-4.8 on Mavericks:
- PTHREAD_MUTEX_RECURSIVE_NP is not defined
- <linux/limits.h> should be <limits.h>
Problems with clang (probably independent of operating system):
- "using namespace std;" can cause problems... in this case it's bind() in Socket.cpp. Replace with ::bind()
I will clean things up tomorrow and try to fix the mysqlconnector, but right now I need some sleep.
- John Adams
- Retired
- Posts: 4581
- Joined: Wed Aug 28, 2013 9:40 am
- Location: Phoenix, AZ.
- Contact:
Re: Building server on Mac OS X
Foof, is this as simple as a separate makefile?
Re: Building server on Mac OS X
[quote="John Adams"]Foof, is this as simple as a separate makefile?[/quote]
Should be just a few #ifdef's in the code and he mentioned a cmake config so that could be something we have separate.
Should be just a few #ifdef's in the code and he mentioned a cmake config so that could be something we have separate.
Re: Building server on Mac OS X
[quote="theFoof"]Should be just a few #ifdef's in the code and he mentioned a cmake config so that could be something we have separate.[/quote]
Yeah... the include file could be fixed with an ifdef.
The problem with bind() is that the code wants bind() from sys/socket.h in the global scope, but it also have "using namespace std" in the global scope so the compiler will call std::bind() which is not the same thing.
I strongly recommend against having any "using namespace" in global scope or in include files since that is doomed to cause problems with different compilers on different platform.
How to solve the problem with PTHREAD_MUTEX_RECURSIVE_NP... I honestly don't know. I usually don't use recursive mutexes so I don't know if it will behave the same as with PTHREAD_MUTEX_RECURSIVE or not. Just have to test I guess.
The linking issue is not really an issue and probably caused by where mysql-libs are installed on Mac.
Yeah... the include file could be fixed with an ifdef.
The problem with bind() is that the code wants bind() from sys/socket.h in the global scope, but it also have "using namespace std" in the global scope so the compiler will call std::bind() which is not the same thing.
I strongly recommend against having any "using namespace" in global scope or in include files since that is doomed to cause problems with different compilers on different platform.
How to solve the problem with PTHREAD_MUTEX_RECURSIVE_NP... I honestly don't know. I usually don't use recursive mutexes so I don't know if it will behave the same as with PTHREAD_MUTEX_RECURSIVE or not. Just have to test I guess.
The linking issue is not really an issue and probably caused by where mysql-libs are installed on Mac.
- John Adams
- Retired
- Posts: 4581
- Joined: Wed Aug 28, 2013 9:40 am
- Location: Phoenix, AZ.
- Contact:
Re: Building server on Mac OS X
Not to offend the Mac users, but I really don't want to add a huge layer of complexity to our core code in 0.1 for such a rare instance. At least not to the committed code. If you fix it, I will be sure to get it integrated into the core if it's not a huge effort.
I thought Mac OS would be fine because it was linux based. If it's some massive effort, we just do not have time at this stage in development. Too many other bugs and stability issues to wade through.
I thought Mac OS would be fine because it was linux based. If it's some massive effort, we just do not have time at this stage in development. Too many other bugs and stability issues to wade through.
Re: Building server on Mac OS X
Oh, I didn't mean that this is something you have to fix. It's more like I'm posting it here for others to read in case they run into similar problems.
I usually play VG when I get home from work, so currently bored with nothing to do until Content Design phase starts, so I started setting up my build pipeline at home.
I have several different build environments that I use. My main computer dualboots win7 and Linux Mint, the server runs Ubuntu Server 12.04 LTS, and my work computer that I develop on when bored at a hotel room on a business trip is a MacBookPro. So I tries to build for all those systems with a shared source repository.
Anyway... here's a patch to get it to build on Mac OS X with both gcc-4.8 and Clang. Next task to avoid boredom is to test it on Win7 with VisualStudio, Eclipse, and QTCreator.
By the way... Mac OS X is not linux based, it's a heavily modified BSD.
I usually play VG when I get home from work, so currently bored with nothing to do until Content Design phase starts, so I started setting up my build pipeline at home.
I have several different build environments that I use. My main computer dualboots win7 and Linux Mint, the server runs Ubuntu Server 12.04 LTS, and my work computer that I develop on when bored at a hotel room on a business trip is a MacBookPro. So I tries to build for all those systems with a shared source repository.
Anyway... here's a patch to get it to build on Mac OS X with both gcc-4.8 and Clang. Next task to avoid boredom is to test it on Win7 with VisualStudio, Eclipse, and QTCreator.
Code: Select all
diff --git a/src/common/Mutex.cpp b/src/common/Mutex.cpp
index 63403ff..e9ad307 100644
--- a/src/common/Mutex.cpp
+++ b/src/common/Mutex.cpp
@@ -220,7 +220,11 @@ RecursiveLock::RecursiveLock(){
#else
pthread_mutexattr_t type_attribute;
pthread_mutexattr_init(&type_attribute);
+# ifdef __linux__
pthread_mutexattr_settype(&type_attribute, PTHREAD_MUTEX_RECURSIVE_NP);
+# else
+ pthread_mutexattr_settype(&type_attribute, PTHREAD_MUTEX_RECURSIVE);
+# endif
pthread_mutex_init(&lock, &type_attribute);
pthread_mutexattr_destroy(&type_attribute);
#endif
diff --git a/src/common/Socket.cpp b/src/common/Socket.cpp
index edf8a85..9b0c62d 100644
--- a/src/common/Socket.cpp
+++ b/src/common/Socket.cpp
@@ -110,7 +110,7 @@ int SocketTCPCreate(const char *host, const char *port, TCPC
if (server) {
setsockopt(sock, SOL_SOCKET, SO_REUSEADDR, &yes, sizeof(yes));
- if (bind(sock, p->ai_addr, p->ai_addrlen) == SOCKET_ERROR) {
+ if (::bind(sock, p->ai_addr, p->ai_addrlen) == SOCKET_ERROR) {
LogError(LOG_TCP, 0, "Unable to bind when creating TCP socket o
SOCKET_CLOSE(sock);
ret = SOCKET_CREATE_ERR_BIND;
@@ -269,7 +269,7 @@ bool Socket::Create(SocketType type, SocketProtocol protocol
int yes = 1;
#endif
setsockopt(sock, SOL_SOCKET, SO_REUSEADDR, &yes, sizeof(int));
- if (bind(sock, p->ai_addr, p->ai_addrlen) == -1) {
+ if (::bind(sock, p->ai_addr, p->ai_addrlen) == -1) {
LogError(LOG_SOCKET, 0, "Error binding %s %s socket on %s:%s: %
Close();
continue;
diff --git a/src/world/CustomPacket.cpp b/src/world/CustomPacket.cpp
index 616e916..74a5a22 100644
--- a/src/world/CustomPacket.cpp
+++ b/src/world/CustomPacket.cpp
@@ -35,8 +35,10 @@
#include <ctype.h>
#if defined(_WIN32)
# include <Windows.h>
-#else
+#elif __linux__
# include <linux/limits.h>
+#else
+# include <limits.h>
#endif
#include "../common/Util.h"
#include "../common/Log.h"