bugmake - Bugs: bug #18139, make chooses wrong pattern rule


bug #18139: make chooses wrong pattern rule

Submitted by:  Chris Sutcliffe <ironhead>
Submitted on:  Sun Oct 29 00:49:37 2006  
Severity: 3 - NormalItem Group: Bug
Status: DuplicatePrivacy: Public
Assigned to: NoneOpen/Closed: Closed
Component Version: 3.81Operating System: MS Windows
Fixed Release: NoneTriage Status: None

Add a New Comment (Rich MarkupRich Markup):

You are not logged in

Please log in, so followups can be emailed to you.


(Jump to the original submission Jump to the original submission)

Wed Jun 10 02:49:39 2009, comment #10:

I believe this is a duplicate of bug #17752

Paul D. Smith <psmith>
Project Administrator
Tue Oct 31 19:07:45 2006, 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.

Boris Kolpackov <bosk>
Project Member
Tue Oct 31 01:57:01 2006, 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.

Paul D. Smith <psmith>
Project Administrator
Mon Oct 30 20:39:56 2006, 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 Oct 30 19:06:58 2006, 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.

Boris Kolpackov <bosk>
Project Member
Mon Oct 30 13:17:03 2006, 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.

Paul D. Smith <psmith>
Project Administrator
Mon Oct 30 07:00:54 2006, 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.

Boris Kolpackov <bosk>
Project Member
Mon Oct 30 00:37:24 2006, comment #3:

I have since been informed, as you pointed out, that this bug does indeed affect Linux based builds of make as well.

Chris Sutcliffe <ironhead>
Sun Oct 29 04:01:33 2006, comment #2:

It's not true that this is a Windows-only thing. I reproduced it on my Linux system.

Paul D. Smith <psmith>
Project Administrator
Sun Oct 29 00:51:57 2006, 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.

Chris Sutcliffe <ironhead>
Sun Oct 29 00:49:37 2006, 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.

Chris Sutcliffe <ironhead>


(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach File(s):

Attached Files
file #11099:  make_rule_issue.tar.gz added by ironhead (7kB - application/x-gzip - Cygwin based rule isse example)


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -unavailable- added by psmith (Posted a comment)

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.


    Please enter the title of George Orwell's famous dystopian book (it's a date):



    Follow 3 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Wed Jun 10 02:49:39 2009psmithStatusNone=>Duplicate
    Sun Oct 29 00:49:38 2006ironheadAttached File-=>Added make_rule_issue.tar.gz, #11099

    Back to the top

    Powered by Savane 3.1-cleanup