Page 1 of 1
r151: Missing x86.h and x86.cpp
Posted: Sun Aug 10, 2008 16:45
by Gez
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.
Posted: Sun Aug 10, 2008 17:27
by Nash
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...
Posted: Sun Aug 10, 2008 17:46
by Gez
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
Posted: Sun Aug 10, 2008 17:48
by Nash
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?
Posted: Sun Aug 10, 2008 17:49
by Gez
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...
Posted: Sun Aug 10, 2008 18:00
by Nash
Interesting. BTW, how come your EXE requires fmod 4.14.04?
Posted: Sun Aug 10, 2008 18:17
by Gez
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.
Posted: Sun Aug 10, 2008 18:27
by Nash
I don't think so. I've been using nothing but NASM but I still get the unresolved externals.
Posted: Sun Aug 10, 2008 18:36
by Gez
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...
Posted: Sun Aug 10, 2008 18:48
by Nash
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!
Posted: Sun Aug 10, 2008 20:16
by Gez
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...
Posted: Sat Aug 16, 2008 21:52
by Gez
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.