I am using a makefile to compile a program that consists of several files. The error that I'm getting is:

/tmp/ccwntKP7.o: In function 'main':
test.driver.c.text+0x17f): undefined reference to 'PrintWhere'
collect2: ld returned 1 exit status
make: *** [test-driver] Error 1

I'm compiling with makefile, so the commandline reads make test-driver. The file is set up to read the command line:
cc -g -o test-driver test-driver.c c-warmup.o

The test-driver file calls the function PrintWhere this way:
#include "c-warmup.h"
#define DB "c-warmup.db"
int main (int argc, char *argv[])
{
float minGpa = 3.5;
float failGpa = 2.0;
float maxGpa = 4.0;
float eqGpa = 3.2;
int testId = 247;
char testName[80];

strcpy (testName, "Frye, John");
printf ("***************************************************************\n");
printf ("Names, ages of students in file %s \n with name > '%s'\n", DB, testName);
printf ("***************************************************************\n");
PrintWhere (DB, STRUCTSIZE, NAME_OFFSET, STRING, AGE_OFFSET, INTEGER, NAME_OFFSET,
STRING, GREATER, testName);
printf ("\n");
printf ("***************************************************************\n");
printf ("Names, id's of students in file %s \n with id > %d\n", DB, testId);
printf ("***************************************************************\n");
PrintWhere (DB, STRUCTSIZE, NAME_OFFSET, STRING,ID_OFFSET, INTEGER, ID_OFFSET,
INTEGER, GREATER, (char *) &testId);
printf ("\n");
printf ("***************************************************************\n");
printf ("Names, gpa's of students in file %s \n with gpa < %3.1f\n", DB, failGpa);
printf ("***************************************************************\n");
PrintWhere (DB, STRUCTSIZE, NAME_OFFSET, STRING, GPA_OFFSET, FLOAT, GPA_OFFSET,
FLOAT, LESS, (char *) &failGpa);
printf ("\n");
printf ("***************************************************************\n");
printf ("Names, ages of students in file %s \n with gpa = %3.1f\n", DB, maxGpa);
printf ("***************************************************************\n");
PrintWhere (DB, STRUCTSIZE, NAME_OFFSET, STRING, AGE_OFFSET, INTEGER, GPA_OFFSET,
FLOAT, EQUAL, (char *) &maxGpa);

return (0);
}


PrintWhere is created in a seperate file called cwarmup.c, which is called in cwarmup.h

int
PrintWhere (
char *fileName, /* name of the file of records */
int recSize, /* size of each record in bytes */
int fieldOffset1, /* offset of field 1 in record */
char fieldType1, /* field 1 type: 'i', 'f', or 's' */
int fieldOffset2, /* offset of field 2 in record */
char fieldType2, /* field 2 type: 'i', 'f', or 's' */
int fieldOffset3, /* offset of field 3 in record */
char fieldType3, /* field 3 type: 'i', 'f', or 's' */
char compareOp, /* comparison type: '<', '=', or '>' */
char *valPtr) /* pointer to comparison value */

Is it cwarmup or c-warmup?

PrintWhere is created in a seperate file called cwarmup.c, which is called in cwarmup.h


Should be PrintWhere is created in a seperate file called c-warmup.c, which is called in c-warmup.h

1) Please use CODE tags around code and computer output etc.

2) I don't see a copy of your makefile in your post. You posted code, but described a problem likely caused by an error in the makefile, not an error in the code.

What do you mean by "called in" or was that just a typo?

The other .c file needs to include the c-warmup.h file, which is probably OK (but see the comment in post #2).

But that is not enough to get c-warmup.c included at link time. You need something in the makefile to cause c-warmup.o to be created from c-warmup.c and then used.

I think so.

CC= cc
CFLAGS= -g

#Targets

all: driver test-driver

info:
@echo "Type 'make <target>', where <target> is one of: "
@echo " 'makedata' to build data file"
@echo " 'driver' to create the driver"
@echo " 'clean' to delete output & object files & excutable"
@echo "You can also type any other target name you see in the Makefile"
@echo "Anything else you create on your own"

makedata: makedata.c c-warmup.h
$(CC) $(CFLAGS) -o makedata makedata.c

c-warmup.o: c-warmup.c c-warmup.h
$(CC) $(CFLAGS) -c c-warmup.c

test-driver: test-driver.c c-warmup.o makedata
$(CC) $(CFLAGS) cc -g -o test-driver test-driver.c c-warmup.o

driver: driver.c c-warmup.o makedata
$(CC) $(CFLAGS) -o driver driver.c c-warmup.o

clean:
rm -f driver driver.o test-driver test-driver.o \
c-warmup.o c-warmup.db makedata core

What does the error 'Undefined reference' mean?

I guess I don't need the cc and -g on the code line since it is defined.

It means the indicated .o file (test_driver) used that symbol, and no .o file defined that symbol.

Having read more carefully, I see you did link with c-warmup.o and that should have defined the symbol.

So the cause of the problem is not obvious.

Now that I see your makefile, I don't understand why the extra cc on that command line doesn't cause a problem (but I'm not at all an expert in makefiles).

The extra -g might be redundant, but that would not be a problem.

I forget the command for dumping the symbols in a .o file, but that would seem to be the next step in diagnosing the problem:

If the symbol is in c-warmup.o, something is wrong with the command used to link.

If the symbol is not in c-warmup.o, something is wrong with either c-warmup.c or the command used to compile it.

what symbol are you referring to?

Also, I'm wondering why it shows in the error
driver.c: (.text+0x17f):

the part in () instead of showing a line number. Could that indicate a problem?

PrintWhere

Just wanted to know, have you still both cwarmup and c-warmup and, if not, have you tried again to compile?

It compiles before linking. You gave a single cc command to both compile the main source file and link. But cc still does that as two separate operations.

After being compiled, you main source file is a binary file. Its external references are not tied to line numbers in the original source code.

The position of the reference within the binary file is useless information to almost all users. So including that information in the error message may have been bad design for that GNU tool. But that is the way it works, so users of GNU binary tools learn to ignore that.