Makefiles, GCC's -ggdb option, and Valgrind

To get right to the point, Valgrind is reporting filenames and line numbers for errors in some files but not others. The makefiles say to include full debugging info in all compilations, so I would expect identical behavior. The only difference is which makefile the instructions come from.

This is the makefile for my library sources; Valgrind doesn't show line numbers for any of these.

Code:

# Makefile

filesystem.o: filesystem.c filesystem.h
	gcc -ggdb -ansi -c filesystem.c

filesystem.h: list.h

list.o: list.c list.h
	gcc -ggdb -ansi -c list.c

list.h: toolkit.h

toolkit.o: toolkit.c toolkit.h
	gcc -ggdb -ansi -c toolkit.c

And these are my project sources; line numbers are shown for all of them. EDIT: Oh, and ../Jesdisciple is my library directory.

Code:

# Makefile

outliner: main.o outline.o ../Jesdisciple/filesystem.o ../Jesdisciple/list.o ../Jesdisciple/toolkit.o
	gcc -ggdb -ansi -o outliner main.o outline.o ../Jesdisciple/filesystem.o ../Jesdisciple/list.o ../Jesdisciple/toolkit.o

main.o: main.c outline.c outline.h ../Jesdisciple/filesystem.h 
	gcc -ggdb -ansi -c main.c outline.c

outline.h: ../Jesdisciple/filesystem.h

include ../Jesdisciple/Makefile

Can anyone please hint at what I did wrong? Thanks!

P.S. Sorry for bumping Enter a little too soon.

(bump)

You may need to show us what parts it is showing errors in. It is possible that you'll get reports from valgrind inside the C library, in which case you do not get symbols by adding -g to YOUR compile.

--
Mats

Code:

main.o: main.c outline.c outline.h ../Jesdisciple/filesystem.h 
	gcc -ggdb -ansi -c main.c outline.c

You're defeating the purpose of make here. The idea of make is that you only have to compile what needs compiling, as opposed to always compiling both source files.

May I suggest some alternative makefiles that use built-in rules and should perform the same as yours?

Code:

# Makefile
CC = gcc
CFLAGS = -ggdb -ansi
OBJECTS = filesystem.o list.o toolkit.o

filesystem.o: filesystem.c filesystem.h
filesystem.h: list.h
list.o: list.c list.h
list.h: toolkit.h
toolkit.o: toolkit.c toolkit.h

If you want to be really fancy, you can make those dependencies automatically generated.

Code:

# Makefile

CC = gcc
CFLAGS = -ggdb -ansi
OBJECTS = filesystem.o list.o toolkit.o

include depend
.PHONY: depend
depend:
	$(CC) -MM $(OBJECTS) > depend

Likewise for the second Makefile, except you'd probably replace the outliner: target with something like this . . . .

Code:

outliner: $(OBJECTS) $(Jesdisciple_OBJECTS)
	$(CC) $(CFLAGS) -o $@ $^

Anyway, just thought you might want to know more about what make can do . . . .

Mats: I'm pretty sure that's not what I was seeing, but I tried to make a fake error anyway to make sure. That didn't go so well; see below.

dwk: I changed the makefiles and thought everything was fine, but when I tried to make an error in a library source I got a bunch of errors in the project sources about undefined stuff coming from library sources. (And that was after I changed the main source so recompilation would be attempted.) So the library's timestamps are no longer being checked.

When I removed the fake errors and triggered another update for the main source, the troublesome errors remained. I also tried compiling the library sources directly; this showed me some line comments which I removed, but the "bad" errors still didn't leave.

I don't think make's (kinda long) output would be very useful, but it's available upon request.

EDIT: I figured the problem out: Jesdisciple_OBJECTS wasn't defined before use. I reversed the order of dependencies in the makefiles and now have a different problem:

Code:

make: *** No rule to make target `toolkit.c', needed by `toolkit.o'.  Stop.

And I believe the confusion stems from make finding those filenames in the makefile of the project directory (where the variable is expanded). Can I automatically prefix them with ../Jesdisciple/?

EDIT2: I resolved the makefile problem by adding ../Jesdisciple/ to the beginning of every library object and moving them to the project makefile, and then reversing the order of dependencies again so the include was at the bottom. After this, the original problem seems to have disappeared. Thanks!

Here are the makefiles:

Code:

# Makefile
CC = gcc
CFLAGS = -ggdb -ansi
OBJECTS = main.o outline.o

include ../Jesdisciple/Makefile

outline.h: ../Jesdisciple/filesystem.h
outline.o: outline.c outline.h

main.o: main.c outline.h

outliner: $(OBJECTS) $(Jesdisciple_OBJECTS)
	$(CC) $(CFLAGS) -o $@ $^

Code:

# Makefile
Jesdisciple_OBJECTS = filesystem.o list.o toolkit.o

toolkit.o: toolkit.c toolkit.h

list.h: toolkit.h
list.o: list.c list.h

filesystem.h: list.h
filesystem.o: filesystem.c filesystem.h list.h

Thanks!

...Or so I thought. I was rushed this morning, and I actually didn't make an error for Valgrind - just for GCC. I really didn't need to make one for Valgrind as I'm already dealing with several. Here's a good example:

Code:

16 bytes in 2 blocks are definitely lost in loss record 1 of 13
==7693==    at 0x402603E: malloc (vg_replace_malloc.c:207)
==7693==    by 0x804AEFB: split (list.c:206)
==7693==    by 0x804A60E: dir_exists (in /home/chris/NetBeansProjects/Outliner/outliner)
==7693==    by 0x804A77F: dir_create (in /home/chris/NetBeansProjects/Outliner/outliner)
==7693==    by 0x804940F: outline_init (outline.c:31)
==7693==    by 0x804902E: main (main.c:170)

And come to think of it, this only affects filesystem.c.

EDIT: I have no idea what caused it this time, but after I fixed my fake compile error (which I had forgotten about), the line numbers showed up. Sorry for taking your time!