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

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

- Archive::Development (https://www.eqemulator.org/forums/forumdisplay.php?f=621)

- - EQEmu DEV-C++ Howto (updated for 5.5DR1) (https://www.eqemulator.org/forums/showthread.php?t=11316)

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

Quote:

Originally Posted by monrezz

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

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

Code:

c:\dev-cpp\bin\dlltool --input-def zlib.def --dllname zlib1.dll --output-lib c:\dev-cpp\lib\libzlib.a -k

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.

Quote:

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)

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.

Code:

LockMutex::LockMutex(Mutex* in_mut, bool iLock) {

150        mut = in_mut;

151        locked = iLock;

152        if (locked) {

153        //-->        mut->lock();

154        }

}

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

Quote:

was actually an access violation in ntdll.dll. For some reason everything works when I commented out line 153 from Mutex.cpp.

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.

Quote:

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.

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

98SE. Maybe some sort of DOS emulator would work? :?

I've tried everything from emulators to downloading the newest version of Dev-Cpp and can't get anywhere. :cry:

I've got one more question, then I'll shut up and wait for the binaries:
Would it be possible to compile windows binaries using G++ on Linux? I know it's a bit far-fetched, and I couldn't find anything about it on google, but I thought it might be worth asking about anyway. :)