bug-make
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: busybox triggers a possible bug in make-3.81rc1 and 3.81beta4


From: Paul D. Smith
Subject: Re: busybox triggers a possible bug in make-3.81rc1 and 3.81beta4
Date: Thu, 9 Mar 2006 18:19:37 -0500

%% Bernhard Fischer <address@hidden> writes:

  bf> busybox is triggering a bug in make-3.81rc1. This bug is at least also
  bf> existing in make-3.81beta4 (from debian).

  bf> current busybox-svn does provoke this with make-3.81beta4, 3.81rc1 and
  bf> cvs-HEAD:
  bf> make: *** No rule to make target
  bf> `/scratch/src/busybox/e2fsprogs/blkid/blkid/blkid_getsize.c', needed by
  bf> `/scratch/obj/bb4/e2fsprogs/blkid/blkid_getsize.o'.  Stop.

The trick here is to notice that there are two instances of the blkid
directory in this path...obviously incorrect.

  bf> but fails with e.g. make from cvs:
  bf> /tmp/m/obj$ rm -rf *.a dir
  bf> /tmp/m/obj$ make --version
  bf> GNU Make 3.81rc1
  bf> /tmp/m/obj$ make -f ../src/Makefile 
  bf> make: *** No rule to make target `/tmp/m/src/dir/dir/a.c', needed by
  bf> `/tmp/m/obj/dir/a.o'.  Stop.
 
And again here: it's /tmp/m/src/dir/dir/a.c instead of the correct
/tmp/m/src/dir/a.c.
 
  bf> Is this a real bug or a user error?

It is a real bug.  It's related to the SECONDEXPANSION capability:
either to the original version, or else to my modification to make it
optional. 

In the new version, the stem (contents of $*) are kept with the target.
In your case, though, there are two different stems: the first one is
the one with the static pattern:

> $(patsubst %,$(objdir)/%,$(THE_OBJS)): $(objdir)/dir/%.o: $(srcdir)/dir/%.c 
> |$(objdir)/dir

Here, the stem for a.c (for example) is "a".  That's fine.

But then, there's _another_ static pattern rule later for these same
targets that looks like this:

> $(MY_OBJS): $(objdir)/%.o: $(srcdir)/%.c

Here, the stem is "dir/a" which is correct for THIS rule.  But, since
there's only one stem stored with any given target, this one overwrites
the first one and when the first rule is expanded, it replaces "%" with
this other stem and you get a bogus prerequisite.

In the case where SECONDEXPANSION is not set this could be resolved by
immediately expanding these prerequisites.  That wouldn't help if
SECONDEXPANSION _is_ set.

It almost seems like we need to move the stem from being a per-target
value to being a per-prerequisite value, since it can change depending
on which prerequisites are being expanded.  The value stored with the
target should be the one used when the commands were defined.

We'll need to think about this.  Can you please file a bug in Savannah
on this issue, adding your tar file as an attachment?

Thanks...


As a workaround, if you like, you can change your makefile so that both
static pattern rules have the same stem.  Then you can also combine the
two static patterns if you like.  Something like this:

MY_OBJS := $(patsubst %,$(objdir)/%,$(THE_OBJS))

$(MY_OBJS): $(objdir)/%.o: $(srcdir)/%.c |$(objdir)/dir
        ...

Obviously, though, this is a bug that needs to be fixed.

-- 
-------------------------------------------------------------------------------
 Paul D. Smith <address@hidden>          Find some GNU make tips at:
 http://www.gnu.org                      http://make.paulandlesley.org
 "Please remain calm...I may be mad, but I am a professional." --Mad Scientist




reply via email to

[Prev in Thread] Current Thread [Next in Thread]