Compiled SDK, now Half-Life is crashing

[sfx1999]

I finally got that SDK to link in MinGW. The solution was so simple (I had to add the parameter -lstdc++ to dllwrap). Anyway, now I keep getting this error:

HL caused an invalid page fault in
module HL.EXE at 017f:01d5ed74.
Registers:
EAX=c439448c CS=017f EIP=01d5ed74 EFLGS=00010206
EBX=0467a370 SS=0187 ESP=0467a0c8 EBP=00000138
ECX=000001eb DS=0187 ESI=000001eb FS=2837
EDX=c439448c ES=0187 EDI=85a92000 GS=0000
Bytes at CS:EIP:
8a 08 40 84 c9 75 f9 4e 75 f6 5f 2b c2 5e c3 90
Stack dump:
00000134 85a92000 01d5ee89 85a92000 0467a370 6fbc0000 00000000 02416de0 00000134 70020188 89ed3027 535c3a43 52524549 41485c41 4c2d464c 5c454649

The problem is that I have no idea how to debug it. It's not like it is the DLL directly causing the page fault. I was wondering if I maybe had to build a new client DLL also? I didn't make any modifications other than the ones required to build it. I have this problem with both SDK 2.2 and 2.3 on half-life version 1.1.1.0.

[Pierre-Marie Baty]

Is your SDK perfectly up to date ? There have been several successive changes released to the SDK 2.3 to make it compatible with newer engine versions.

[botman]

Did you modify the SDK code in any way?

Are you using my SDK 2.2 patches to get it to compile with MinGW?

If you made changes on your own, I would bet that you've changed something incorrectly, possibly passing a pointer to the engine when you shouldn't be or not passing a pointer to the engine when you should be.

I think we will need a lot more detail about what you changed in order to get the SDK to compile with MinGW.

botman

[Pierre-Marie Baty]

Stupid me! how come I didn't think about it yet ?

Grab Will Day's personal SDK, from the metamod website. He made quite a few changes to the normal SDK to have it compile well with recent GCCs, and not only those prehistoric versions Valve was using when they released the first SDK.

If it compiles under Linux GCC, I don't see why it would not compile on MinGW too.

[sfx1999]

botman: I manually installed every one of your patches to 2.3, finding the lines and what not, but I also have this problem with the 2.2 downloaded from your site which I used your patches for.

Pierre-Marie Baty: I will try that. It will probably still need some modifications, though.

[EDIT]

I downloaded that SDK, and I would have to put &classname:: in all settouch, setuse, and setthink functions. I do not want to do that again. And I do not think it would work.

[sfx1999]

I guess no one understood what I was saying. Let me explain this again.

I downloaded 2.3 and modified it so it would compile. I put &classname:: where I needed to (setuse, setthink, settouch, setmovedone), and I also moved some declarations out of loops (instead of for (int i=0, i<30, i++), I took int i out of the function and made it (i=0, i<30, i++)). In a couple of files I added #include <ctype.h>. However, I also have the problem when I downloaded 2.2 from botman's site and patched it with the patcher. I am sure it patched right. I did not make ANY modifications after that, because I need to make sure it works before I do.

[Pierre-Marie Baty]

Looks like you too haven't understood what I was saying

It is NORMAL that you can't compile SDK 2.3 on MinGW, because MinGW uses recent GCC compilers, which are the same as the Linux compilers. Compiling SDK 2.3 on MinGW is just as if you were compiling it on Linux. And the problem is that the guys at Valve were using a pretty outdated version of GCC to compile the SDK on Linux.

That's why SDK 2.3 does NOT natively compile on Linux, and that's why it cannot compile in MinGW too - because the Linux/MinGW compilers are recent ones.

That's also why, you shouldn't use the normal SDK if you want to compile it on MinGW, but Will Day's SDK, because he fixed a lot of things in it to have it compile on Linux. And if it compiles on Linux, it must be pretty close to compile on MinGW too, since they are the same compilers.

[sfx1999]

But I did get it to compile. The problem is that my MinGW uses newer standards. I can tell his WILL NOT compile with MinGW unless I modify it, which I am going to do now. I pray that I won't get any invalid page faults...

[Pierre-Marie Baty]

you may get it compile OK, you may get link it OK too, but it doesn't mean the DLL will run. That's because HL uses a wicked way to pass entities addresses from one DLL to the other ; with a MSVC-style exports name mangling, it always work, but with other compilers, sometimes it does, but most often it doesn't. And this is the main problem we are facing.