Win32 Compile

[iori]

Hi kids, I was just wondering about what is needed to compile the most recent c++ cvs checkout, and Exl told me that he couldnt because of errors to do with the netcode and/or renderer.
He was using MiniGW win32 to compile apparently, and I was told it wouldnt compile under MSVC++6. It's not extremely important, but I was curious (I do have the latest copy of the compiling docs and have the correct libs i believe). Thanks.

[Exl]

g++ -c -O -Wall -mwindows -D__WIN32__ -DSDL -DHWRENDER -I../include g_mapinfo.cpp -o ../objs/g_mapinfo.o
In file included from d:/mingw/include/c++/3.2.3/cstring:51,
from d:/mingw/include/c++/3.2.3/bits/char_traits.h:45,
from d:/mingw/include/c++/3.2.3/string:47,
from ../include/g_mapinfo.h:84,
from g_mapinfo.cpp:93:
../include/parser.h:108: previous declaration of `char* strlwr(char*)' with C++
linkage
d:/mingw/include/string.h:168: conflicts with new declaration with C linkage
../include/parser.h:105: previous declaration of `char* strupr(char*)' with C++
linkage
d:/mingw/include/string.h:176: conflicts with new declaration with C linkage


That's error msg. number one. There were lots of warnings, and more fatal errors after this one. I hope it's something I just don't know (yet).

[Hurdler]

humm, do you know which version of gcc you use? I personnaly use gcc 3.3.4 (under Linux). The error you put here looks like a gcc incompatbility. I don't mean it's not a problem with the source code (it should compile on most gcc version if possible), but maybe using a more (or less) recent version of gcc might help for now.

[smite-meister]

Looks like gcc 3.2.3 to me :)

I still don't understand why you get this error. The most current parser.h should have

#ifndef __WIN32__
/// converts a c-string to upper case
char *strupr(char *s);

/// converts a c-string to lower case
char *strlwr(char *s);
#endif

to overcome this annoying "feature" of MinGW.

[Exl]

Reinstalled MinGW and the earlier slew compilation errors were fixed. Next up is this one;

make[1]: Entering directory `/d/doom/legacy/cvsroot/doomlegacy_c++/video'
g++ -c -O -Wall -mwindows -D__WIN32__ -DSDL -DHWRENDER -I../include png.cpp - o ../objs/png.o
png.cpp: In member function `byte* PNGTexture::ReadData(bool)':
png.cpp:218: `alloca' undeclared (first use this function)
png.cpp:218: (Each undeclared identifier is reported only once for each
function it appears in.)
make[1]: *** [../objs/png.o] Error 1


(libpng 1.0.17)

[Pate]

Try adding

#include<alloca.h>

To the start of the png.cpp. It might help, then again it might not. *diablo*

[Exl]

Rrrright ... *whatever*

[Hurdler]

feel free to commit your changes once you can compile it without errors ;)

[Exl]

Just to be sure, Pate's suggestions didn't help (I'm almost positive he was joking). Should I sort out whatever I change with WIN32 ifdefs?

[Pate]

I wasn't. alloca.h is actually required on some platforms, but apparently not on Windows. Usually the memory functions are declared in stdlib.h, which should be included.

Usually you should use #ifdefs, but only on platform dependent things, not actual bugs. Though sometimes telling them apart can be a bit tricky.

[smite-meister]

alloca allocates temporary memory from the stack, and it should be defined in stdlib.h.
In Linux, I guess png.h automatically includes stdlib.h, but feel free to add the line
#include <stdlib.h>
to png.cpp. No need to use #ifdef __WIN32__ around it.

[Exl]

Including stdlib.h didn't change a thing. Adding #include <malloc.h> did the trick however.

Edit: Next up;g++ -c -O -Wall -mwindows -D__WIN32__ -DSDL -DHWRENDER -I../../include i_system.cpp -o ../../objs/i_system.o
i_system.cpp: In function `int TranslateJoybutton(unsigned char, unsigned
char)':
i_system.cpp:237: warning: `int base' might be used uninitialized in this
function
i_system.cpp: In function `char* I_GetUserName()':
i_system.cpp:780: invalid conversion from `Uint32*' to `DWORD*'
i_system.cpp: In function `void I_GetDiskFreeSpace(long long int*)':
i_system.cpp:932: invalid conversion from `Uint32*' to `DWORD*'
i_system.cpp:932: invalid conversion from `Uint32*' to `DWORD*'
i_system.cpp:932: invalid conversion from `Uint32*' to `DWORD*'
i_system.cpp:932: invalid conversion from `Uint32*' to `DWORD*'
make[1]: *** [../../objs/i_system.o] Error 1

[Exl]

*small bump*

[smite-meister]

Okay, try this:
Change the types of the variables causing the errors from Uint32 to DWORD.
Tell me if it works :)

[Exl]

Ok, that worked. I'm now up to the point where the linker wants the tnl and libtomcrypt libs. This is where I got stuck before; I tried compiling the tnl libs myself but MinGW would then just spew at me that the tnl functions can't be found. I take it the library I compiled isn't entirely correct... once more (and hopefully the last time), how would this be fixed?

[Hurdler]

Did you succeed compiling tnl? if so, just put the library generated in the same directory as you mingw lib directory, or use -L/path/to/tnl/lib/ (see the makefile)

if not, maybe someone will be smart enough to put a link precompiled libs here.

[Exl]

Okay, TNL compiled and linked, the next thing being:
objs/hwr_geometry.o(.text+0xb44):hwr_geometry.cpp: undefined reference to `glClientActiveTexture@4'
I tried including some other of the GL libs for linking but to no success. Some searching for glClientActiveTexture didn't turn up with much either.

[smite-meister]

I had the same problem, but I really can't remember how I solved it. *ugh*
Anyway, the function should be found in the main OpenGL import library (called either libGL.a or libopengl32.a), there is no need to include any extra libs.

What is the version of your MinGW release?

[Exl]

Version 3.1.0.1

[Hurdler]

It requires OpenGL 1.3 (or higher) headers (gl.h) and libs.
If you haven't them, maybe you can simply try adding ARB after glClientActiveTexture (glClientActiveTextureARB).

If it's a real problem to get OpenGL 1.3+, we can add the following code
#ifndef GL_VERSION_1_3
#define glClientActiveTexture glClientActiveTextureARB
#endif

[Exl]

With or without the ifdefs, it didn't help. It just complained about not finding glClientActiveTextureARB otherwise.

[Hurdler]

ok, then, it's not the headers and/or libs for OpenGL 1.2.1 either.
Well, maybe smite-meister can remember what he did ;)
For now, you can remove that call in the source code since the code in the CVS doesn't use textures if I remember well (even if it's texture ready).

[Exl]

Seems smitemeister has some things left to fix with that bbox class before it would compile at all. I'll wait patiently ;)
Edit: Ok, my waiting paid off quick, it compiled almost perfectly. Thanks for the time!

[smite-meister]

What do you mean by "almost"? :)

BTW, I've been workin on merging the ACBot code to the C++ version.
I'll commit the stuff during the weekend.

[Exl]

Almost as in a slew of warnings that were there since I first checked out the branch a year ago ;)

[Hurdler]

Warnings are not that important if they are not bugs. We fix them from time to time (most of them depends on GCC version used and we add voluntary some of them like #warning network code not yet finished ;))
If it runs, that's the most important.

[MR_ROCKET]

yo exl , send me that compiled version :P

[Exl]

Drop by #legacy sometime and I will :)

[MR_ROCKET]

Roger ,i'm on right now although its 6 pm here , i'll try an catch you sometime this week in the morning. :)

[Exl]

Try earlier :P I'm only on in the evenings during weekdays. Doesnt matter anyway, a silly HD fuckup and a reformat later leaves me without the files to build it ATM.

[MR_ROCKET]

I'll try heh and no prob man , I'm sure you'l have thing squared away soon enough , a loss of data always sucks , good luck with that :\

Actually was sorta wanting to scan through the things table again , which ever might come first , I'm sure it wont be long until