> "Paul" == Paul D Smith <[EMAIL PROTECTED]> writes:
Paul> Doh. I don't know what I was thinking. This one is easy. Your
Paul> rule is:
Doh is right. Sorry to have bothered you with that part of it :-(
Mahalo,
Jim
> "Paul" == Paul D Smith <[EMAIL PROTECTED]> writes:
Paul> It seems like you've got some serious memory corruption here, but
Paul> I've never seen anything like this before.
Paul> You don't have a copy of Purify lying around anywhere, have you?
Paul> If not, the dmalloc libra
Doh. I don't know what I was thinking. This one is easy.
Your rule is:
%$(EXE): %.c
@echo EXE -$@- from -$<-
@$(RM) $@
$(COMPILE.c) $<
$(LINK.c) $(subst ../,,$(basename $<))$(OBJ) $(LDLIBS)
@echo end EXE
COMPILE.c is:
COMPILE.c = $(CC) $(CFLAGS) $(
The bogus paths in the -p output can be fixed by changing line 708 in
read.c from this:
if (r < 2)
to this:
if (!r)
I can reproduce the other problem, but I haven't tracked it down yet.
It doesn't seem to be a memory error, at first blush--anyway, Purify
doesn't com
It seems like you've got some serious memory corruption here, but I've
never seen anything like this before.
You don't have a copy of Purify lying around anywhere, have you? If
not, the dmalloc library will do; if you have a copy you can configure
make with --enable-dmalloc and rebuild and see i
Aloha,
I'm trying to debug a problem of some sort in a make. The output from
make -p is included below. If you've seen something like the original
problem before, I'd appreciate a clue. The actual commands lost something
between the "%: %.c" rule shown in the dump and their execution - the RM
