Wed 10 Jun 2009 02:49:39 AM UTC, comment #10:
I believe this is a duplicate of bug #17752
|
Tue 31 Oct 2006 07:07:45 PM UTC, comment #9:
I just checked and this code is in 3.80. I could not find any motivation of doing things this way in the comments.
|
Tue 31 Oct 2006 01:57:01 AM UTC, comment #8:
Hm. Boris, is that the way it's always worked or is it something we changed recently? According to the docs as far as I can tell there's no such distinction between rules that require intermediates and those that don't. In fact, it seems pretty clear that this distinction is not intended; the docs on chaining say:
> There are some special implicit rules to optimize certain cases that
> would otherwise be handled by rule chains. For example, making `foo'
> from `foo.c' could be handled by compiling and linking with separate
> chained rules, using `foo.o' as an intermediate file. But what
> actually happens is that a special rule for this case does the
> compilation and linking with a single `cc' command. The optimized rule
> is used in preference to the step-by-step chain because it comes
> earlier in the ordering of rules.
The last sentence would not be necessary if the two passes model were in place, since the "no intermediates" path would be chosen regardless of which order it appeared in.
|
Mon 30 Oct 2006 08:39:56 PM UTC, comment #7:
I think the confusion comes from that the top-goal in the makefile is not what it actually should be, that is just:
all: $(LIBS)
Normally you would expect this to work but by the implications that Boris mentionned it doesn't.
Tnen, there are (at least) 3 criteria make uses on search for a pattern rule:
- file exists
- file "ought to exist"
- file can be made (intermediate)
Unfortunately what "ought to exist" means and when its applied remains highly unobvious in normal practice, but it is actually the point of change between 3.80/81.
--- grischka
|
Mon 30 Oct 2006 07:06:58 PM UTC, comment #6:
When GNU make is trying to match a target to an implicit rule it does it in two passes (implicit.c:432): first without intermediate prerequisites and then with them. If %.o results in an interemdiate then, on the first pass, the first rule will be ignored and the second one will be used.
|
Mon 30 Oct 2006 01:17:03 PM UTC, comment #5:
Boris, I don't see why %.o being intermediate makes a difference. Make can and does chain implicit rules. I re-read the section on chaining and I don't see anything that would contradict the basic premise of chaining, which is that the length of the chain doesn't matter, only the order in which they're defined in the makefile. Of course I could be forgetting something.
I realize that just because someone works differently in 3.81 doesn't mean it's broken; however in this case I really do think that 3.80 was correct... unless, as I mentioned, I'm missing some special case.
|
Mon 30 Oct 2006 07:00:54 AM UTC, comment #4:
I haven't checked the archive but from the rules above it seem that this is the valid behavior if %.o in the first rule would trigger build of an intermediate target.
Also note that there were tons of bugs fixed in 3.81 compared to 3.80. Automatically assuming that if something worked in 3.80 and doesn't work in 3.81 then it must be a bug in 3.81 is not quite correct--ideally it should be pointed in the GNU make manual or POSIX standard why certain behavior is expected.
|
Mon 30 Oct 2006 12:37:24 AM UTC, comment #3:
I have since been informed, as you pointed out, that this bug does indeed affect Linux based builds of make as well.
|
Sun 29 Oct 2006 04:01:33 AM UTC, comment #2:
It's not true that this is a Windows-only thing. I reproduced it on my Linux system.
|
Sun 29 Oct 2006 12:51:57 AM UTC, comment #1:
I've been told that the correct behaviour is used in the GNU/Linux version of Make 3.81 (i.e. the first rule is used), so this may be a windows only issue.
|
Sun 29 Oct 2006 12:49:37 AM UTC, original submission:
In the attached archive there is a Makefile that contains 3 rules:
lib%.a : %.def %.o
$(DLLTOOL) $(DLLTOOL_FLAGS) --output-lib $@ --def $(srcdir)/$*.def
$(AR) r $@ $*.o
$(RANLIB) $@
lib%.a: %.def
$(DLLTOOL) $(DLLTOOL_FLAGS) --output-lib $@ --def $<
lib%.a: %.o
$(AR) rc $@ $*.o
$(RANLIB) $@
In versions of make prior to 3.81, the first rule was used for creating import libraries that were comprised of both .def and object file. In version 3.81, the first rule is skipped and the second rule is used, as a result, the exported functions and definitions in the object files are not included in the import library.
|