Linux Smaug Makefile Help

Posted by Klered on Wed 29 Sep 2004 07:27 PM — 7 posts, 22,679 views.

#0
Hi -

RH9 - Linux
GCC - compiling in the shell

Im having a problem linking:
Smaug 1.4a (customize over the past 4 years)
Original Distribution was a Nick Gammon port to Win32
(the code has numerous ifdef WIN32 statements, but still should compile -
might not be stable until removed...etc)
-I have checked lots or archives but still I can't find out the issue
RH9 - Linux
GCC - compiling in the shell

problem seems to be alot of undefined references - seems that mud.h

Here is my makefile - and the errors below .
Please Help??
__________________
CC = gcc
PROF =
NOCRYPT =
C_FLAGS = -g3 -Wall $(PROF) $(NOCRYPT)
L_FLAGS = $(PROF)
LIBS = -lcrypt
MAKE = make
# Uncomment the two lines below if compiling on a Solaris box
#SOLARIS_FLAG = -Dsun -DSYSV
#SOLARIS_LINK = -lnsl -lsocket

#Uncomment the line below if compiling on a RedHat (and possibly other
Linux) box
LINUX = -DLINUX
# The program executable's name
PROG_NAME = smaug
#Uncomment the line below if you are getting implicit decleration of re_exec
REG = -DREGEX

#Uncomment the line below if you are getting undefined re_exec errors
NEED_REG = -lgnuregex
O_FILES = act_comm.o act_info.o act_move.o act_obj.o act_wiz.o boards.o \
build.o clans.o comm.o comments.o const.o db.o deity.o fight.o \
handler.o hashstr.o ibuild.o ident.o interp.o magic.o makeobjs.o \
mapout.o misc.o mpxset.o mud_comm.o mud_prog.o player.o
polymorph.o \
requests.o remort.o reset.o save.o shops.o skills.o special.o tables.o \
track.o update.o grub.o stat_obj.o ban.o services.o planes.o \
imm_host.o colorize.o

C_FILES = act_comm.c act_info.c act_move.c act_obj.c act_wiz.c bank.c
boards.c \
build.c clans.c comm.c comments.c const.c db.c deity.c fight.c \
handler.c hashstr.c ibuild.c ident.c interp.c magic.c makeobjs.c \
mapout.c misc.c mpxset.c mud_comm.c mud_prog.c newarena.c
player.c polymorph.c \
requests.c remort.c reset.c save.c shops.c skills.c special.c tables.c \
track.c update.c grub.c stat_obj.c ban.c services.c planes.c \
imm_host.c colorize.c

H_FILES = mud.h bank.h bet.h imc-config.h imc-mercbase.h imc-mercdefs.h
imc.h \
ice.h icec.h icec-mercbase.h

all:
@echo ""
@echo " Checking Perished Lands History Record, Please wait... "
@$(MAKE) $(PROG_NAME)
@echo " ..done"

$(PROG_NAME): $(O_FILES)
@echo ""
@echo " Compiling Perished Lands MUD...Please wait "
@rm -f $(PROG_NAME)
@$(CC) $(L_FLAGS) -o $(PROG_NAME) $(O_FILES) $(LIBS)

.c.o: mud.h
$(CC) -c $(C_FLAGS) -DNOCRYPT $<

clean:
@echo " performing a Make-Clean "
@rm -f *.o $(PROG_NAME) *~
@echo " ..done"
@echo


--------HERE IS THE RESULT -----
Compiling Perished Lands MUD...Please wait
act_wiz.o(.text+0x2399): In function `do_authorize':
/root/mudstuff/smaug/src/act_wiz.c:703: undefined reference to `do_quit'
act_wiz.o(.text+0x2e17): In function `do_deny':
/root/mudstuff/smaug/src/act_wiz.c:917: undefined reference to `do_quit'
act_wiz.o(.text+0x30a4): In function `do_fquit':
/root/mudstuff/smaug/src/act_wiz.c:992: undefined reference to `do_quit'
act_wiz.o(.text+0x1018f): In function `do_mortalize':
/root/mudstuff/smaug/src/act_wiz.c:5078: undefined reference to `do_quit'
act_wiz.o(.text+0x1076a):/root/mudstuff/smaug/src/act_wiz.c:5153:
undefined reference to `do_quit'
act_wiz.o(.text+0x10ac0):/root/mudstuff/smaug/src/act_wiz.c:5214: more
undefined references to `do_quit' follow
act_wiz.o(.text+0x22338): In function `do_doublexp':
/root/mudstuff/smaug/src/act_wiz.c:10667: undefined reference to
`sportschan'
act_wiz.o(.text+0x223d6):/root/mudstuff/smaug/src/act_wiz.c:10682:
undefined reference to `sportschan'
comm.o(.text+0x1a6): In function `main':
/root/mudstuff/smaug/src/comm.c:224: undefined reference to
`init_pfile_scan_time'
comm.o(.text+0x686e): In function `nanny':
/root/mudstuff/smaug/src/comm.c:2815: undefined reference to `scan_rent'
db.o(.text+0x1ee3): In function `boot_db':
/root/mudstuff/smaug/src/db.c:724: undefined reference to
`load_equipment_totals'
db.o(.text+0x1ee8):/root/mudstuff/smaug/src/db.c:725: undefined
reference to `scan_equipment'
db.o(.text+0x210b):/root/mudstuff/smaug/src/db.c:769: undefined
reference to `fread_questmaster'
fight.o(.text+0x98e1): In function `raw_kill':
/root/mudstuff/smaug/src/fight.c:3443: undefined reference to `sportschan'
fight.o(.text+0xc246): In function `do_kill':
<snip for length>
update.o(.text+0x5ecb):/root/mudstuff/smaug/src/update.c:2362:
undefined reference to `quest_update'
collect2: ld returned 1 exit status
make[1]: *** [smaug] Error 1
make[1]: Leaving directory `/root/mudstuff/smaug/src'
make: *** [all] Error 2
USA #1
You said 'customize over the past 4 years'. There seems to be many functions that are undefined. Try adding those to mud.h
USA #2
No. Adding them to a header file won't help since this error is in the linking phase.

It looks like do_quit and a few other functions aren't defined in your code even though they are declared. (That's why you get a linker error and not a compiler error - if it wasn't declared, it would give you an error at compile time.)

My suggestion is to first start with a make clean; make; and if that doesn't work go find out if those functions exist in the code and if there aren't any #ifdef blocks that are preventing their compilation.
#3
Thanks Sincerely for Replying to this albeit Cry for help.

I have been working hard on getting my first RH 9 distrubution going so its been a long week of configuring. I really thought I had checked everything on the Makefile, but since I don't code for a living, I still make novice mistakes. First, let me say that my code is compiled. Next Id like to point out what the solution was - my C files and my O files were poorly mapped. I went through my C files - some of were left off the make file, and I added them manually. I didn't add an 'O' file for each 'C' - I also was missing 2 'H' files - so because the source code was missing - the linker freaked out.

What is interesting to me is that I have been coding in MSC++ for 4 years - and only a couple of times did I even open the Makefile. Tell me if I am wrong - but I think MSC++ holds the dependent info in it's 'workspace' settings.

Now that I am compiling in GCC in the shell, I am going to have to relearn/learn some things I took for granted using that other program.

Tell me something - if I include a 'depend' command in my Makefile - would it auto-create all my Cflags, Oflags, Hflags, etc?

Still learning, TX in advance.

KL
USA #4
VC++ stores the dependency information in the project settings, yes, or perhaps even recalculates it every time. Many makefiles do the same thing, by having a first step of producing dependency information and a second step of acting on it.

Quote:
Tell me something - if I include a 'depend' command in my Makefile - would it auto-create all my Cflags, Oflags, Hflags, etc?
I'm not sure I quite understand what you mean, but there are tools like 'automake' that will generate makefiles for you - you still need to fill in libraries and the like, but it'll create a makefile that compiles the source files in your directory. You can also do things like 'make depend' in some circumstances which will generate dependency chains.
#5
Ksilyan -

Yes thanks - you did get it right - I was asking about Make Depend - while sorting out my makefile - I tried several experiments and used Make Depend - in the final version, I took it out - I do not want all my .C files added to the executable. Simply because there are still some code I am working on.

I finally got everything sorted late last night - lots of reformatting directories and area file names etc, the game seems to be running real well, and I only had to GDB - bt a couple of times. Thats a great tool. I recommend everyone read Nick Gammon's GDB primer if you compile in the Shell or need to debug your game. It took me 30 minutes to figure out and I solved 2 major problems getting my system up and running. Granted my code is clean - so I didn't expect too many issues - at least it was in Win32.

So for the record - I used the Win32 build of Smaug1.4a - from Nick Gammon - which I would like to thank him for that - it is great - and further more - I have successfully ported it to redhat 9. Now for some rest =)

Cheers!

Klered
USA #6
Congratulations, I'm glad to hear you worked out your problems and have it running. :)

And yes, Nick's guide truly is of very good quality.