EQEmu DEV-C++ Howto (updated for 5.5DR1)
 

Here is a HOWTO to get EQEmu 5.3DR2 (01/01/2004 version) to compile
with Bloodshed Dev-C++ / mingw.

http://www.rama.demon.co.uk/EQEmu-Dev-C++.zip

Most of the changes were trivial. The two biggest headaches were:

1) Dev-C++ won't by default link against the mysql libraries

I have included instructions on how to create a libmysql.a

2) vsnprintf would SIGSEGV every time.

In the end I found a portable version of vsnprintf written in C
which I have included in the zip, and included in the HOWTO details
of where to put #ifdefs to use this version when compiling under Dev-C++.

I have also included .dev files for Emusharemem/world and zone (similar to VS .NET's .SLN fies).

I have only tested briefly under minilogin and it seems stable enough.

EDIT: The following added for 5.5DR1

The source tree for 5.5DR1 with Dev-C++ changes already made is available here:

www.rama.demon.co.uk/5.5DR1DevCPPSource.zip

I found out why vsnprintf wasn't working, so the 5.5DR1 zip no longer uses the 'portable vsnprintf', rather there are changes to allow the standard vsnprintf to work. As a result, any bugs (such as non-functioning #npcspawn add) relating to the use of the portable vsnprintf should be gone.

Great contribution!!! 8)

this has just made my day maaaaan thank you!

Let me know if you get it to work :D

well sadly it didn't compile right =(
here are the errors i get:
86 C:\eqemu\5.3dr2dev\common\debug.h
In file included from ../common/debug.h
1 C:\eqemu\5.3dr2dev\EMuShareMem\Doors.cpp
from Doors.cpp
C:\eqemu\5.3dr2dev\common\Portable_vsnprintf.h
[Warning] In function `int portable_vsnprintf(char*,:
3 C:\eqemu\5.3dr2dev\common\Portable_vsnprintf.h
previous declaration of `int
225 C:\Dev-Cpp\include\stdio.h
conflicts with new declaration with C linkage
C:\eqemu\5.3dr2dev\EMuShareMem\Makefile.win
[Build Error] [Doors.o] Error 1

Thanks Shadow-Wolf. Give me a day or two and I will see if I can figure out what is wrong. BTW can you give me a link to the EQEmu source that you are using ?

well im using the source from shawns cvs
http://shawn319.eqemulator.net/cvs/ no changes made to it except for the ones you said to add

Don't add the

to common/types.h (or remove it if you did). That was an error that slipped in while I was reworking the changes and compiling the howto.

Very nice job! Should make quite a few people happy.
Dang! that makes an F#$%ing HUGE zone.exe!

First a note, I updated to mingw 3.3.1


In world\console.cpp
is missing the # on the if

I had to add -D_GLIBCPP_USE_C99 -D_GLIBCPP_USE_C99_DYNAMIC to the dev files.

I got when compiling world


For perl support:
c:\dev-cpp\bin\reimp -d c:\perl\lib\core\perl58.lib
c:\dev-cpp\bin\dlltool --input-def perl58.def --dllname perl58.dll --output-lib c:\dev-cpp\lib\perl58.a -k

and the beginning of zone_perl.devI didn't do any testing besides compiling it.


FYI The changes didn't have an effect on compiling in MSVC++6 :)
Not that they should have.

Any developers using bloodshed want to join the dev team ?

Well, nice job Tertiary, amazing !

I compiled without real trouble using your fixes, with dev-cpp 4.9.8.0. things i did :
--added Portable_vsnprintf.h/cpp to the project files
--changed -lzlib to -lzlib1 (i used the pre-compiled zlib1.dll from www.zlib.org)
--adapted the directories to my configuration

Thank you for porting eqemu to BloodShed, that's great of you, nice to have it compiling on a free w32 compiler ! :)

ps : zone.exe weights 10

for zone.dev,
project -> project options -> compiler [tab] -> linker -> generate debugging information = yes

reduced zone.exe to 2

ok, i got eqmemshare.dll compiled nothing bad so far but when i try to compile world.exe i get these errors:

console.cpp C:\eqemu\5.3dr2dev\world\console.cpp
In member function `void Console::ProcessCommand(const char*)':
682 C:\eqemu\5.3dr2dev\world\console.cpp
parse error before `(' token
686 C:\eqemu\5.3dr2dev\world\console.cpp
`Ver_name' undeclared (first use this function)

(Each undeclared identifier is reported only once for each
687 C:\eqemu\5.3dr2dev\world\console.cpp
`Ver_build' undeclared (first use this function)
687 C:\eqemu\5.3dr2dev\world\console.cpp
`ultoa' undeclared (first use this function)
688 C:\eqemu\5.3dr2dev\world\console.cpp
`Ver_min' undeclared (first use this function)
689 C:\eqemu\5.3dr2dev\world\console.cpp
`Ver_maj' undeclared (first use this function)
690 C:\eqemu\5.3dr2dev\world\console.cpp
`Ver_pid' undeclared (first use this function)
34 C:\eqemu\5.3dr2dev\world\console.cpp:691
#elif without #if
694 C:\eqemu\5.3dr2dev\world\console.cpp
`GetOS' undeclared (first use this function)
34 C:\eqemu\5.3dr2dev\world\console.cpp:695
#else without #if
34 C:\eqemu\5.3dr2dev\world\console.cpp:697
#endif without #if
749 C:\eqemu\5.3dr2dev\world\console.cpp
jump to case label
385 C:\eqemu\5.3dr2dev\world\console.cpp
crosses initialization of `Seperator sep'
C:\eqemu\5.3dr2dev\world\Makefile.win
[Build Error] [console.o] Error 1

zone.exe compiled fine except this error
\Dev-Cpp\Bin\..\lib\gcc-lib\mingw32\3.2\..\..\..\..\mingw32\bin\ld.exe C:\eqemu\5.3dr2dev\zone\C
cannot find -lzlib

For the first part of your problem, correct the typo that Lurker pointed out. In world\console.cpp, add a # to the front of
For your second problem, the makefile is looking for zlib.dll in the C:\dev-cpp\lib folder, so make sure you have a copy of it over there and you should be alright.

I do have a problem of my own, though, that maybe someone could help with. Apparently I'm not installing or using reimp right. When I try to run World.exe or Boot5Zones, I get this error:

Is there a certain directory I should be in when I run the reimp and dlltools commands? Do I have to add any files anywhere else? I ran both of those commands as listed just from whatever directory I happened to be in. I installed MinGW 3.1.0-1 in the dev-cpp\bin folder (and also have an install sitting in dev-cpp\bin\MinGW and also have all the contents of MinGW\bin sitting in the bin directory). When I run those two commands it pops up a new command prompt without an error, like the command went through. Any help would be greatly appreciated.

Oh, and great package, Tertiary!

yay got it working now you rock tertiary!(and dingo01
for his bit of help)

wouldn't know what to do about your problem mine worked fine when i used it.

dingo01 do you have a copy of libmysql.dll somewhere in your path, or in your EQEmu dir?

Also The Dev-cpp compiled files seemed to work fine with one exception, they didn't close cleanly. World has an error about reading memory, and then the zones have to be forced to close.


And I can confirm that the perl quests work as well. See my post earlier.

The only place I had libmysql.dll was in C:\mysql\bin and C:\mysql\lib\opt. I've kind of given up on it for now, though, since I just saw that the DR2 binaries were released, and those work great.

Thanks, though!

I assume you mean using 'worldshutdown' from the console, or #worldshutdown from the client ?

Does this happen all the time ? I did some tests today and worldshutdown closes the world and zone processes cleanly each time for me.

Actually I usually just kill the dos box :?
And again I am using mingw 3.3.1 not sure what differances that makes.

world.exe and zone.exe are now asking for libmysql.dll

I did a search on my Hd and found quite a few. I've tried a few but having been gettin strange errors regarding memory access when I attempt to close the window (the window closes after I hit ok and the new compilation seemed to work just fine). I was mainly curious as to what this bug is and if it's related to me not knowing which libmysql.dll to use.

how do i get reimp out of a mingw-utils-0.2.tar?????

More specifically how do i use a .tar file. Nothing i have will open the file!!

Tar is a standard storage format for the unix (linux) OS

While there should be several utils for windows that will read it, you can get tar from http://gnuwin32.sourceforge.net/packages.html

Winzip is known to be able to work with tarball files, and even with tar.gz files.

when compiling world.dev i have the following errors

console.cpp C:\eqemu\5.3dr3dev\world\console.cpp
In member function `void Console::ProcessCommand(const char*)':
684 C:\eqemu\5.3dr3dev\world\console.cpp
`GetOS' undeclared (first use this function)

(Each undeclared identifier is reported only once for each
687 C:\eqemu\5.3dr3dev\world\console.cpp
`Ver_name' undeclared (first use this function)
688 C:\eqemu\5.3dr3dev\world\console.cpp
`Ver_build' undeclared (first use this function)
688 C:\eqemu\5.3dr3dev\world\console.cpp
`ultoa' undeclared (first use this function)
689 C:\eqemu\5.3dr3dev\world\console.cpp
`Ver_min' undeclared (first use this function)
690 C:\eqemu\5.3dr3dev\world\console.cpp
`Ver_maj' undeclared (first use this function)
691 C:\eqemu\5.3dr3dev\world\console.cpp
`Ver_pid' undeclared (first use this function)
C:\eqemu\5.3dr3dev\world\Makefile.win
[Build Error] [console.o] Error 1

someone else had a problem similar to this and dingo01 said to ..
I did that and used the precompiled zlib.dll and it does not fix my problem.

If you can zip up your source dir and email it to me at eqemu@rama.demon.co.uk I will take a look at it and try and see where you are going wrong ... it will be quicker than trying to second guess where you (or I ) might have made a mistake.

Any further queries regarding a Dev-C++ compile should really go in Win32 server support, as it is really not an EQEmu development issue.

Great work Tertiary! Nice contribution to the community :)

The file sizes are huge compared to the binaries - is there any way of compressing them or optimizing them so they are smaller?

Please could one of the Dev's merge this with the CVS?

Nice work,

Monrezz

The .dev files I included with my .zip have debugging information turned on for world or zone (or both). See Muuss' post earlier in this thread for how to turn this off which will make the files smaller.

What exactly does rebuild all do, compared to just compiling? I tried compiling EmuShareMem.dll and World.exe - both compiled fine without errors, and work. Not tried zone as you said it would crash/fail to compile. What does the rebuild all do...?

Turned off the debugging - thanks!

if I download the source again I assume it is going to overwrite the changes I (you) made to the files. Is there a quick way of putting it all back in, or will I just have to wait until a dev decides your code should be merged with CVS? :)

Monrezz

If you just select compile, it will only re-compile source files that have changed since you last compiled everything ... normally this is what you want, since it makes recompiling quicker, i.e. if you only change one source file, only that one will be recompiled.

The problem Dev-C++ has is that common/database.cpp has an #ifdef ZONE statement which compiles extra code if you are building zone.exe.

Unfortunately Dev-C++ is not smart enough to know that it should recompile this file when you compile zone.exe ... as far as it is concerned there have been no changes to database.cpp since it last compiled it (when you built world.exe), hence you need to do a 'rebuild all' to force it to recompile database.cpp.

Hope that makes sense.

There is a util called diff which could be used to create context diffs between the official source and the source patched to compile under Dev-C++. Then you could just apply this 'diff' using the 'patch' command when you download the latest source from CVS.

patch and diff come with MSYS (www.mingw.org) ... I just haven't been motivated enough to produce a diff, so for now, adding the changes back by hand is what you need to do.

So you only need to Rebuild All on the zone.exe compile - the other 2 you can just Compile?

Yeah that made sense, thanks again!

You sir, are a God :D

Monrezz

Well Emusharemem.dll you can just compile as normal. You should use rebuild all for world and zone to be on the safe side.

If you are just tinkering with the source code for one or the other (world or zone), doing a rebuild all for the first compile of the session and then just a normal compile for any subsequent changes should be fine, since you can be sure that the database.cpp has been compiled correctly for the program you are tinkering with.

Hey there, I just got DR3 compiled cleanly and thought I'd chime in with a couple tips for those who are new to Dev-C++ (like me! ;))

1. If you have your files installed to different paths, you will need to edit the World.dev and Zone.dev project files. In the Project menu, select Project Options(Alt+P). On the main tabs, click "Directories". Then on the sub tabs, click "Include Directories".
Here you can edit the default paths.

2. I got an error with the file errmsg.h when trying to compile database.cpp. I solved it by adding the \common directory to my project "Include Directories" (see above). The path will probably be different for you, but for me c:\EQEmu\devr3\common\ seemed to do the trick. I also added errmsg.h to the Common Header Files (under the project tab on the left hand side of the IDE).

3. If you are getting an error with something about -lzlib in the makefile, it means you don't have the proper library (libzlib.a) in your /Dev-Cpp/lib/ folder. To fix this problem, you can download http://www.zlib.net/zlib121-dll.zip and extract it to your zlib folder. In the /zlib/lib folder there will be a file called zlib.def . You can use this to create your missing libzlib.a file, just like how you created the libmysql.a file in the HOW-TO. In the console run this command, and remember to change paths where necessary

Big thanks to Tertiary and all the other helpers for getting this figured out (and cuz this is my first post) big thanks to the whole team :D Having a lot of fun with this.

One question though, why the heck are the .exe's so big? My zone file is 10mb. Do .NET or VC6 compilers make it smaller?

Edit: Well, they compiled cleanly, but now when I run either zone.exe or world.exe I get an "Unhandled Win32 Exception in process 3500(this varies)". Bleh, well, I'll keep at it.

I have seen a few people have this problem. I think all I did to get zlib to link was to copy c:\mysql\lib\opt\zlib.lib to c:\dev-cpp\lib.

The reason your zone.exe is so big is because it is built with debugging turned on (see Muuss's post earlier in the thread).

To see where world.exe is crashing (needs to be built with debugging info turned on) try:

c:\dev-cpp\bin\gdb world.exe

At the (gdb) prompt, type run

And it should tell you what function it crashed in. You can do the same for zone.exe:

c:\dev-cpp\bin\gdb zone.exe

At the (gdb) prompt:

set args . 127.0.0.1 7995 localhost
run

If you want me to verify that the crashes aren't due to a possible mistake you might have made when editing the source, delete all the .o .exe and .dll files from your source directory (do Execute/Clean for each of the three projects), zip up your source directory and email it to me at eqemu@rama.demon.co.uk.

Yeah, I actually used drmingw to track down the crashing. I should of been more specific, it was actually an access violation in ntdll.dll. For some reason everything works when I commented out line 153 from Mutex.cpp.

The released R3 binaries work alright, so it's a bit strange. I'll look into it further when I've got the time. Oh, and even with debugging turned off, everything is still at least twice the size of the released binaries (this isn't a complaint, I'm just curious).

Strange. What OS are you running ? I would still be interested in a copy of your source directory if you have time to zip and send it. I've not heard of this problem before, but there is no way of knowing whether other people might have tried to compile with Dev-C++ and had the same problem but not bothered to post about it.

To get Zone.exe to close cleanly you need to include Perl - see the post earlier. Don't forget to add embperl.h etc to the File list. Now when you close Zone.exe with the checkbox it shutdown and tells World.exe not to reboot it. If it crashes, it reboots.

Not sure about World.exe - just ignore that error.

Monrezz

Does this work with 5.5DR1? I am getting alot of errors rebuilding.

Alright, here's a fun one for all of you trouble-shooters. :)

I've downloaded win CVS, installed it, and downloaded the latest source. I followed the instructions in the zip file (thanks Tertiary!), and compiled.

All three compiled without error, but when I went to copy them I couldn't find world.exe and zone.exe, so I tried recompiling them both and checked the console output.

After a lot of testing I've found that for reasons unknown DOS gives a bad command or filename error if the command exceeds 444 characters, thus why the less complex (as far as number of included files anyway) EmuSharemem.dll compiled, while the exes didn't.

Now, my question is; does anyone know of a way around this (a 32 bit version of G++ maybe?) or am I just going to have to stick to the binaries? :(

What version of Windows are you running ? (I tested this under XP).