PDA

View Full Version : build probs


dumbledore
11-07-2005, 02:09 AM
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
11-07-2005, 06:35 AM
Hmmm, interesting. Which code branch are you using and have you made any modifications to it?

dumbledore
11-07-2005, 04:30 PM
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
11-07-2005, 06:07 PM
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
11-07-2005, 06:14 PM
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
11-07-2005, 07:36 PM
that's my guess. ;)

razorace
11-07-2005, 08:59 PM
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
11-07-2005, 11:15 PM
new to these forums, semi-undercover, i'm known in other forums by a different name ;P
figured i'd poke around in some modding stuff, and what better to look at than an opensource one ;)

razorace
11-07-2005, 11:37 PM
Ah, gotcha. :) Well, welcome to LucasForums. Are you new to JKA editting then?

dumbledore
11-07-2005, 11:59 PM
yep. :) i do a bunch of random programming though, so i'm not 100% illiterate :P
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
11-08-2005, 02:59 AM
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
11-08-2005, 03:55 PM
windir is an environment var on most win32 systems, so mingw32-make sees it as already defined. ;)

razorace
11-08-2005, 04:44 PM
ahhh! I only use VS.net so most of this is handwaving to me. :)

dumbledore
11-08-2005, 11:13 PM
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 :P

dumbledore
11-10-2005, 10:11 PM
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
11-10-2005, 11:05 PM
I honestly don't know. I didn't know that gcc could output to the .dll format.

dumbledore
11-11-2005, 12:36 PM
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
11-11-2005, 02:44 PM
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
11-11-2005, 05:00 PM
nope. do some google-ing. ;)

razorace
11-11-2005, 05:33 PM
So, why are you trying to compile it like an .so then?

dumbledore
11-11-2005, 05:42 PM
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.