r151: Missing x86.h and x86.cpp

Post by **Gez** » Sun Aug 10, 2008 16:45

I copied those from ZDoom r1147 but it doesn't compile anyway because whines about an unresolved external symbol _realviewheight in tmap.obj.

After regenerating the whole project, I got new and exciting problems, but they've been solved by copying the asm directories from ZDoom into GZDoom's own project tree.

And it seems to work okay now.

Post by **Nash** » Sun Aug 10, 2008 17:27

I can't get it to compile at all even after a fresh GZDoom SVN checkout and copying the files and directories you mentioned.

Can you post your EXE? I really really want the latest GZDoom...

Post by **Gez** » Sun Aug 10, 2008 17:46

Updating. It's r151M, disregard the M, the only file that's changed is the vcprj because I had to manually correct the missing dependency.
gzdoom_r151.zip - 1.80MB

Post by **Nash** » Sun Aug 10, 2008 17:48

Is that the reason why I get this?

Code: Select all

4>Linking...
4>zstrformat.obj : error LNK2019: unresolved external symbol @freedtoa@4 referenced in function "int __fastcall StringFormat::VWorker(int (__fastcall*)(void *,char const *,int),void *,char const *,char *)" (?VWorker@StringFormat@@YIHP6IHPAXPBDH@Z01PAD@Z)
4>zstrformat.obj : error LNK2019: unresolved external symbol @dtoa@28 referenced in function "int __fastcall StringFormat::VWorker(int (__fastcall*)(void *,char const *,int),void *,char const *,char *)" (?VWorker@StringFormat@@YIHP6IHPAXPBDH@Z01PAD@Z)
4>../gzdoom.exe : fatal error LNK1120: 2 unresolved externals

I'd like to learn what this kind of error really means so that in future I can fix them on my own. Can you explain to me what to do if an error like this comes up? Does it mean that the VCPRJ file has a missing dependency?

And thanks for your EXE. Do I have permission to upload it to my executable archive online?

Post by **Gez** » Sun Aug 10, 2008 17:49

What's funny is that I've tried a new global regeneration afterwards and this time I get a flood of unresolved external symbols. Apparently it has to be compiled first without the asm dirs, and then with them in a second time. Or something. It's voodoo...

Post by **Nash** » Sun Aug 10, 2008 18:00

Interesting. BTW, how come your EXE requires fmod 4.14.04?

Post by **Gez** » Sun Aug 10, 2008 18:17

No idea.

Anyway, I've found the real culprit. It's yasm. I've tried yasm in between my two compilations of gzdoom, in order to try it for a ZDoom compilation. Yasm just isn't as good as nasm.

Post by **Nash** » Sun Aug 10, 2008 18:27

I don't think so. I've been using nothing but NASM but I still get the unresolved externals.

Post by **Gez** » Sun Aug 10, 2008 18:36

I've regenerated it entirely three times with nasm without problem. Everytime I've tried yasm it couldn't generate the assembly files and then created all those unresolved externals...

Post by **Nash** » Sun Aug 10, 2008 18:48

That's really weird.

Anyway, after much hair-pulling, eye-bulging and cleaning/rebuilding solutions, I finally got GZDoom r151 to compile.

These have got to be by far the most difficult set of revisions to compile, EVER!

Post by **Gez** » Sun Aug 10, 2008 20:16

Okay, the list of missing files include:
x86.h
x86.cpp
wrappers.asm
and both asm directories.

And of course glext.h and wglext.h. I was trying to get rid of that silly M tag and I ended up erasing the whole directory and redownloading everything. As always, I forgot to back these two up...

Post by **Gez** » Sat Aug 16, 2008 21:52

This and this (and I guess this too?) can be closed now. With the missing files committed and the project file updated, these compile errors do not happen anymore.