EQEmulator Forums - Windows Binary Compiling Guide

EQEmulator Forums (https://www.eqemulator.org/forums/index.php)

- Support::Windows Servers (https://www.eqemulator.org/forums/forumdisplay.php?f=587)

- - Windows Binary Compiling Guide (https://www.eqemulator.org/forums/showthread.php?t=35722)

I was pretty surprised to see the links go dead so fast.
I'll be moving my boards pretty soon to a host instead of keeping it local and will post a link for people that might want files. Tho I know at least a half dozen people that frequent this board already mirror all the files for others.

http://www.activestate.com/activeperl/downloads shows 5.14 and 5.16 when i just checked. but yeah 5.12 was there a couple days ago

Alright. So I've fiddled with EQEmu a little while, previously running Win32 versions without a hitch (well, ok, small hitches here and there, but never in the compiling stage) so I decided I would have a go at a new install (as in everything installed, Win64 versions of everything), but this time going with VS2010 Prof and the guide in this thread (which honestly, Akkadius has made this so simple, I think, that the guide itself isn't needed, it all compiles just fine -- for the most part?).

However, I'm having an issue with World.exe

Here is the compile log for World.exe (and of course its dependency):

Code:

1>------ Build started: Project: EMuShareMem, Configuration: Release x64 x64 ------

1>Build started 9/15/2012 3:48:06 PM.

1>InitializeBuildStatus:

1>  Creating "x64\Release x64\EMuShareMem.unsuccessfulbuild" because "AlwaysCreate" was specified.

1>ClCompile:

1>  DLLMain.cpp

1>  Doors.cpp

1>  Items.cpp

1>  Loot.cpp

1>  MMF.cpp

1>  NPCFactionLists.cpp

1>MMF.cpp(325): warning C4532: 'return' : jump out of __finally block has undefined behavior during termination handling

1>  NPCTypes.cpp

1>  Opcodes.cpp

1>  SkillCaps.cpp

1>  Spells.cpp

1>  debug.cpp

1>  Mutex.cpp

1>  SharedLibrary.cpp

1>  timer.cpp

1>Link:

1>     Creating library .\../Build/EMuShareMem/EMuShareMem.lib and object .\../Build/EMuShareMem/EMuShareMem.exp

1>  EMuShareMem.vcxproj -> C:\EQEmuSVNFiles\EQEmu\trunk\EQEmuServer\x64\Release x64\EMuShareMem.dll

1>FinalizeBuildStatus:

1>  Deleting file "x64\Release x64\EMuShareMem.unsuccessfulbuild".

1>  Touching "x64\Release x64\EMuShareMem.lastbuildstate".

1>

1>Build succeeded.

1>

1>Time Elapsed 00:00:05.17

2>------ Build started: Project: World, Configuration: ReleaseBots x64 x64 ------

2>Build started 9/15/2012 3:48:11 PM.

2>InitializeBuildStatus:

2>  Creating "x64\ReleaseBots x64\World.unsuccessfulbuild" because "AlwaysCreate" was specified.

2>ClCompile:

2>  Adventure.cpp

2>  AdventureManager.cpp

2>  client.cpp

2>  cliententry.cpp

2>  clientlist.cpp

2>  console.cpp

2>  EQLConfig.cpp

2>  EQW.cpp

2>  EQWHTTPHandler.cpp

2>  EQWParser.cpp

2>  HTTPRequest.cpp

2>  LauncherLink.cpp

2>  LauncherList.cpp

2>  lfplist.cpp

2>  LoginServer.cpp

2>  LoginServerList.cpp

2>  net.cpp

2>  perl_EQLConfig.cpp

2>  perl_EQW.cpp

2>  perl_HTTPRequest.cpp

2>  queryserv.cpp

2>  wguild_mgr.cpp

2>  world_logsys.cpp

2>  WorldConfig.cpp

2>  worlddb.cpp

2>  zonelist.cpp

2>  zoneserver.cpp

2>  ucs.cpp

2>  Anniversary.cpp

2>  Client62.cpp

2>  Underfoot.cpp

2>  HoT.cpp

2>  VoA.cpp

2>  Patches.cpp

2>  SoD.cpp

2>  SoF.cpp

2>  Titanium.cpp

2>  Base64.cpp

2>  BasePacket.cpp

2>  classes.cpp

2>  Condition.cpp

2>  CRC16.cpp

2>  crc32.cpp

2>  database.cpp

2>  dbasync.cpp

2>  dbcore.cpp

2>  DBMemLeak.cpp

2>  debug.cpp

2>  emu_opcodes.cpp

2>  EMuShareMem.cpp

2>  EmuTCPConnection.cpp

2>  EmuTCPServer.cpp

2>  EQDB.cpp

2>  EQDBRes.cpp

2>  EQEmuConfig.cpp

2>  EQEMuError.cpp

2>  EQPacket.cpp

2>  EQStream.cpp

2>  EQStreamFactory.cpp

2>  EQStreamIdent.cpp

2>  EQStreamProxy.cpp

2>  eqtime.cpp

2>  extprofile.cpp

2>  File.cpp

2>  guild_base.cpp

2>  guilds.cpp

2>  HttpdCookies.cpp

2>  HttpdForm.cpp

2>  HttpdSocket.cpp

2>  HTTPSocket.cpp

2>  Item.cpp

2>c:\eqemusvnfiles\eqemu\trunk\eqemuserver\common\socketlib\httpsocket.cpp(115): warning C4715: 'HTTPSocket::ProcessReceivedData' : not all control paths return a value

2>  logsys.cpp

2>  logsys_eqemu.cpp

2>  md5.cpp

2>  MemFile.cpp

2>  Mime.cpp

2>  misc.cpp

2>  MiscFunctions.cpp

2>  moremath.cpp

2>  Mutex.cpp

2>  opcodemgr.cpp

2>  packet_dump.cpp

2>  packet_dump_file.cpp

2>  packet_functions.cpp

2>  Parse.cpp

2>  perl_EQDB.cpp

2>  perl_EQDBRes.cpp

2>  races.cpp

2>  rulesys.cpp

2>  serverinfo.cpp

2>  shareddb.cpp

2>  SharedLibrary.cpp

2>  socket_include.cpp

2>  StructStrategy.cpp

2>  TCPConnection.cpp

2>  TCPServer.cpp

2>  timeoutmgr.cpp

2>  timer.cpp

2>  tinystr.cpp

2>  tinyxml.cpp

2>  tinyxmlerror.cpp

2>  tinyxmlparser.cpp

2>  Utility.cpp

2>  XMLParser.cpp

2>Link:

2>  World.vcxproj -> C:\EQEmuSVNFiles\EQEmu\trunk\EQEmuServer\x64\ReleaseBots x64\World.exe

2>FinalizeBuildStatus:

2>  Deleting file "x64\ReleaseBots x64\World.unsuccessfulbuild".

2>  Touching "x64\ReleaseBots x64\World.lastbuildstate".

2>

2>Build succeeded.

2>

2>Time Elapsed 00:01:04.10

========== Build: 2 succeeded, 0 failed, 0 up-to-date, 0 skipped ==========

Upon running, here is the error I am receiving:

Code:

The application was unable to start correctly (0xc000007b). Click OK to close the application.

From research, it's either a .NET issue (for those not running 4.0 which I am) or from those attempting to run using a dependency/DLL that is Win32 and the program is Win64, or vice versa.

Well.. All I know is, my EMuShareMem.DLL is being compiled into the /x64/Release x64" directory and my World.exe is being compiled into my /x64/ReleaseBots x64" where I would think they should be.

So, I'm at a loss. As you may have assumed, I am indeed attempting to compile a ReleaseBots x64 version (bots version). I did take notice though configuration manager in VS2010 that "queryserv" defaulted on a "Release" configuration and not "Release x64". But I noticed this after the first and second attempt (after cleaning and rebuilding, just in case) to build the project. So I changed it to "Release x64", even though I believe it would make little to no difference to World.exe or the .DLL since they don't depend on it, but, figured, what the heck.

At any rate.. 4 hours in, I'm just as clueless as to the issue as I was when I first received the error.

Any ideas?

Make sure you clean your solution before you compile and that you are pulling fresh binaries and the .dll from each of the target directories.

The target directories could probably be changed so it all makes sense but that is the way it was created initially by Secrets. I thought about changing that stuff as well but didn't get around to it.

I might look at it but I have a ton of stuff going on right now, lots of personal stuff as well as some huge stuff that I've been working on for PEQ as well.

Cleans = always done before building, just gives me a peace of mind if nothing else

Target Directories = eh, it didn't hurt my brain to figure out where to find them, the queryserv however was in "Release" (32 bit) because by default in the configuration manager it was selected as only "release" (which I assume is 32 bit). A quick simple change to "Release x64" compiled it in 64 bit and it ended up then in the "Release x64" directory

I'm compiling and running on the same machine.

I'm using the following:

Windows 7 Home x64
MySQL 5.5 x64
Perl 5.14.2 Build 1402

Then again, I think I see the problem, maybe?

For the 5.14 download link you have for "64 bit builds" you have:

Code:

http://projecteqemu.googlecode.com/files/ActivePerl-5.14.2.1402-MSWin32-x86-295342.msi

Instead of:

Code:

http://downloads.activestate.com/ActivePerl/releases/5.14.2.1402/ActivePerl-5.14.2.1402-MSWin32-x64-295342.msi

Not sure, but I can tell you, the Perl version I'm running/have installed on the machine for purposes of running the server is the one that is linked here and that is as shown above.

I'll download the 64 bit version of 5.14.2 of Perl, install that and see if World.exe still vomits or not.

Yes that would do it, I was totally distracted while updating these links. They are updated again. My fault.

Quote:

Originally Posted by Akkadius (Post 212523)

Yes that would do it, I was totally distracted while updating these links. They are updated again. My fault.

Hey, no worries, the work you do around here and all that seems to be going on at the homefront... you're human, imagine that ;)

Just glad it was that and not some long serious issue on my end. I about stuck with 32bit.

Akkadius box.com is a great site for uploaded items if its allowed by admin for posting the url link.

Is it normal to receive a flood of warnings about deprecated functions?

VS 2010 C++ Express using pre-packed perl/zlib/sql libs and includes on a freshly imaged Win Srv. 2008 R2 machine.

It would seem that a good 70-80% of the compile log states either "Possible Loss of Data" or "(Performance Loss)".

Yes, the warnings are normal.

Just a thought, what about using CMake (like TrinityCore does for their WoW emu)?

I don't know if that's been discussed anywhere, and I don't know a thing about getting it set up - just how to use it, so I don't know if it would simplify or complicate things.

The CMake for windows GUI is pretty easy and it should help to build the required files for any compiler

Quote:

Originally Posted by nosfentora (Post 212854)

KLS is working on CMake right now, but in the meantime everyone has the flexibility of using much simpler to compile VS solutions. Plus if you are developing and making changes it is much less of a headache

CMake can create the Visual Studio solutions and then you can use those to compile and have the nice IDE. Unfortunately for those that have trouble compiling in the first place, adding CMake to the mix is just one more step to get wrong.

My thought on CMake was that at least you'll have a visual checklist or what needs to be included and error list for what is missing, ie mysql lib, perl lib, etc etc.

at least how TC is set up, you select the source path, then point it to your mysql files (and for them openSSL, but for us would be perl and zlib) and generate.

it'll spit out what's missing if the user forgot to set something up.

i always thought that was an easier way to get things to compile than we've currently got implemented. especially since different compilers (ie versions of VS) get set up differently.

just my $0.02

Edit:

If i'm not mistaken, if new source is pulled and cmake is not run, when compiling VS will attemt to run CMake to generate the updated solution. At least 2010 does.