build probs

[dumbledore]

theoretically, since you can build this w/ gcc on linux, shouldn't mingw on windows work too? yet when i use the makefile provided i get this:

D:\projects\OJP\OJP\Basic\source\game>make
gcc -fPIC -DFINAL_BUILD -DNDEBUG -DMISSIONPACK -DQAGAME -D_JK2 -D__linux__ -marc
h=i586 -O3  -c NPC_AI_Civilian.c -o NPC_AI_Civilian.o
NPC_AI_Civilian.c:1: warning: -fPIC ignored for target (all code is position ind
ependent)
In file included from g_local.h:6,
                from b_local.h:6,
                from NPC_AI_Civilian.c:4:
q_shared.h:269:1: warning: "ID_INLINE" redefined
q_shared.h:169:1: warning: this is the location of the previous definition
q_shared.h:279:1: warning: "PATH_SEP" redefined
q_shared.h:178:1: warning: this is the location of the previous definition
In file included from g_local.h:6,
                from b_local.h:6,
                from NPC_AI_Civilian.c:4:
q_shared.h:290: error: redefinition of 'BigShort'
q_shared.h:171: error: previous definition of 'BigShort' was here
q_shared.h:292: error: redefinition of 'BigLong'
q_shared.h:173: error: previous definition of 'BigLong' was here
q_shared.h:294: error: redefinition of 'BigFloat'
q_shared.h:175: error: previous definition of 'BigFloat' was here
q_shared.h:1294: error: conflicting types for 'powf'
q_shared.h:1294: error: conflicting types for 'powf'
In file included from g_local.h:9,
                from b_local.h:6,
                from NPC_AI_Civilian.c:4:
g_public.h:711: error: redefinition of typedef 'Vehicle_t'
bg_vehicles.h:6: error: previous declaration of 'Vehicle_t' was here
make: *** [NPC_AI_Civilian.o] Error 1

D:\projects\OJP\OJP\Basic\source\game>

[razorace]

Hmmm, interesting. Which code branch are you using and have you made any modifications to it?

[dumbledore]

i used the basic branch from the cvs tutorial, haven't made any edits... well i did but reverted back to the old version just to double-check...

 

[edit] er, that's both cvs HEAD and cvs OJP_BASIC i've tried, failed on both...

[dumbledore]

actually, i finally found the problem. both win32 and __linux__ were being defined, so what i did was add this:

#if defined(GNUC) && ( defined(_WIN32) || defined(WIN32) )
#undef _WIN32
#undef WIN32
#endif

to q_shared.h and added -DGNUC to the gcc compile line. you might want to incorporate something like this into the codebase since not everyone has enough $$$ to buy ms vc7

[razorace]

when/where was it defining win32 and __linux__? I thought they were defined in the preprecessor settings for the makefiles. Oh wait, it's probably because you're using mingw?

[dumbledore]

that's my guess.

[razorace]

The win32 probably being autodefined by the mingw compiler. I suppose I could add this fix to the source code when I have time.

 

So, what you new around here or are you just undercover?

[dumbledore]

new to these forums, semi-undercover, i'm known in other forums by a different name

figured i'd poke around in some modding stuff, and what better to look at than an opensource one

[razorace]

Ah, gotcha. Well, welcome to LucasForums. Are you new to JKA editting then?

[dumbledore]

yep. i do a bunch of random programming though, so i'm not 100% illiterate

btw, i tried to clean up the makefile a bit to account for differences between linux and windows, as well as put the obj files in a separate dir so there aren't so many random files in the dir. here's the result:

# Linux Makefile for Jedi Academy MP SDK
# By Patrick Hemmer
# Version 2
# 
# Created Nov 29, 2003
# The Void - http://www.divoid.net
#
# You may set your own optimizations on the CFLAGS line. If you dont know what optimizations are, then just leave it as is.
# Run 'make' to compile the code, once done, you will have a file called 'jampgamei386.so' in the 'game' directory. Copy this file to the 'base' folder of your server or to your mod folder.
# If for some strange reason, you are running on less than a 586 processor, change the i586 to i386 on the CFLAGS line.
# edit on Nov 7, 2005 - puts objs in an obj dir so there's less clutter, and also automatically compiles more .c sources
# for better flexability / expandability

CC = gcc
CFLAGS = -fPIC -DFINAL_BUILD -DNDEBUG -DMISSIONPACK -DQAGAME -D_JK2 -D__linux__ -DGNUC -march=i586 -O3 
ifdef windir
TARGET = jampgamex86.dll
else
TARGET = jampgamei386.so
endif

sources = $(wildcard *.c)
OFILES = $(patsubst %.c,obj/%.o,$(sources))

obj/%.o : %.c
$(CC) $(CFLAGS) -c $< -o $@

$(TARGET) : $(OFILES)
$(CC) -shared -o $(TARGET) $(OFILES) -lm

clean:
rm -f $(OFILES)
rm -f $(TARGET)

and the reason there's the #define conflicts is obviously ravensoft / whatever wasn't thinking about using gcc/win32 to compile, those #ifdefs should actually use some msvc-specific define instead of using the entire platform.

 

also, i tested the output using the "make-a-mod" "slow rockets" tut thingy and it worked great the only thing extra i did which the makefile doesn't do was strip the debugger symbols out of the dll with gnu strip, but i don't think that's necessary, just cuts down on the size a bit

[razorace]

I never added strip to the makefile because I normally use the internal symbols for debugging when I get into trouble with undefined symbols.

 

I should probably add stripping as a "final" command arguement to the makefile or something.

 

So, when is windir defined?

[dumbledore]

windir is an environment var on most win32 systems, so mingw32-make sees it as already defined.

[razorace]

ahhh! I only use VS.net so most of this is handwaving to me.

[dumbledore]

hm, can i build the cgame and ui dlls with mingw too? or am i out of luck there :/...

i got something to compile, but jamp likes to replace it with the base dlls for me O_o, and after i replaced the base dlls with the new dlls, it sort of crashed while loading the players (it did seem to work fine up to that point, though...)

 

btw, nice sig, that used to be my fav game

[dumbledore]

further investigation shows that everything works fine as far as the menus go, but when i try to load up a game via create a game, it crashes returning from CG_NewClientInfo (yes, returning, it executes all the code in the function, but the next line of code from the caller function is never executed O_O O_o)... any possible insight? my only idea is possibly a stack / memory corruption... :/ the error message says that the memory could not be "read" at location 0x000000 by the instruction at 0x0000000 too O_o

[razorace]

I honestly don't know. I didn't know that gcc could output to the .dll format.

[dumbledore]

gcc -shared -o mydll.dll myofile.o myotherofile.o -lmylinkedlib

there's some other things you need to do too though, like specify which functions are exported in the code..

[razorace]

So, a .dll file is just a renamed .so file? I don't think that's correct. I'm pretty sure there's more to it.

[dumbledore]

nope. do some google-ing.

[razorace]

So, why are you trying to compile it like an .so then?

[dumbledore]

http://www.mingw.org/mingwfaq.shtml#faq-msvcdll

Assume we have a testdll.h, testdll.c, and testmain.c. In the first case, we will compile testdll.c with MinGW, and let the MSVC-compiled testmain call it. You should use

 

gcc -shared -o testdll.dll testdll.c \

-Wl,--output-def,testdll.def,--out-implib,libtestdll.a

 

to produce the DLL and DEF files.