[solved!] GMutex.h Compile Fatal (Cata r12330, Win7 64bit, VS2010U)

[suommynona]

Hello reporting a compilation failure:

Win7 64bit

MaNGOS Master (WoW Cataclysm)

r12330

trying to compile following this guide: https://github.com/mangos/server/blob/master/README

Visual Studio 2010 Ultimate Version 10.0.40219.1 SP1Rel

Microsoft .NET Framework Version 4.0.30319 SP1Rel

mangosdVC100.sln

Release

Win32

Build -> Clean Solution

Build -> Build Solution

========== Build: 9 succeeded, 3 failed, 0 up-to-date, 0 skipped ==========
55 errors, 17 warnings

54 of these:

Description: error C1083: Cannot open include file: 'unistd.h': No such file or directory
      File: ..\\server\\dep\\include\\g3dlite\\G3D\\GMutex.h
      Line: 15
    Column: 1
   Project: game

1 of this:

Description: error LNK1181: cannot open input file '..\\server\\win\\VC100\\game__x64_Release\\game.lib'
      File: ..\\server\\win\\VC100\\LINK
      Line: -
    Column: -
   Project: mangosd

trying x64:

Release

x64

Build -> Clean Solution

Build -> Build Solution

========== Build: 9 succeeded, 3 failed, 0 up-to-date, 0 skipped ==========
55 errors, 64 warnings

Same errors as with Win32.

Research:

GMutex.h, as an external dependency, has an included header file by the name of unistd.h which I seem to be missing.

#include <unistd.h>

Searching the forums, I stumbled only upon this:

http://getmangos.eu/bb/topic/586/solved-make-compile-error/

At first this topic seemed unrelated to my problem (ubuntu/linux/mac), then suddenly a wild GMutex appears:

Hello all,

Succefully compiled!

Problem solved by adding

#include <unistd.h>

into server/dep/imculde/g3lite/G3D/GMutex.h

Thank you all for your help and shlainn for the golden ticket!

Regards,

which was a problem fix suggested by shlainn:

Try adding

#include <unistd.h>

to the includes of dep/g3dlite/include/G3D/GMutex.h

From (http://www.trinitycore.org/f/topic/6211-usleep-not-found/)

Puzzling that a fix to one problem causes mishaps for someone else. But that's about all the intel I have.

I might need a dev's help on this. Please help.

Is there a problem with GMutex.h in my code? Should I just remove the include line?

Am I building the solution badly? Should having a 64bit Win7 OS make an x64 Release work better than a Win32 one?

Do I have a wrong version of Visual Studio? What version do you recommend that would compile the code successfully?

Am I supposed to run CMake first anyways, even though the README suggests to go straight for the .sln files in the win/ directory, since I'm running Windows?

Thank you for any help.

[evilatwow]

Is there a problem with GMutex.h in my code? Should I just remove the include line?

The very short answer: no, and yes

A bit more to the point then: the unistd.h that you see there is the name of a header file that is included to allow access to the POSIX operating system API, so typically for "UNIX and alike" systems. The typical Windows/Visual Studio application (not counting Cygwin/MinGW applications here) doesn't need the file, and since it's not part of the Visual Studio or Windows SDK installation, most likely you don't even have it.

If all you want is to build your own server on your own Windows system, simply removing the include will fix that problem for you. Windows XP or Windows 7, 32-bit or 64-bit, Visual Studio version... it doesn't matter, you don't need it. You can keep using the Visual Studio solutions too, no need for cmake as far as I remember.

However, the include seems to be needed for the UNIX alike systems. So if you want to build the server on say Linux, you'll need it and in that case you can't remove it (but in that case you shouldn't have this problem in the first place).

The real fix is thus to make the include conditional, so it only gets included on Windows when building with Visual Studio or something. Not sure what the best option is here... but something like this is a start:

#ifndef _MSC_VER
#include <unistd.h>
#endif

That avoids the include if you're compiling with Visual Studio

Happy building!

[suommynona]

Indeed, a bit more googling hinted me toward it being some kind of unix thing so I took the liberty and hastily commented out the line. The compilation went through smooth as a hot knife through butter.

It was a bit of an experimental solution though, what you posted is much cleaner, I like it.

Much appreciated.

Solved!