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

 
 

bug #18139: make chooses wrong pattern rule

Submitter:  Chris Sutcliffe <ironhead>
Submitted:  Sun 29 Oct 2006 12:49:37 AM UTC
   
 
Severity:  3 - Normal Item Group:  Bug
Status:  Duplicate Privacy:  Public
Assigned to:  None Open/Closed:  Closed
Component Version:  3.81 Operating System:  MS Windows
Fixed Release:  None Triage Status:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

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

I believe this is a duplicate of bug #17752

Paul D. Smith <psmith>
Group administrator
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.

Boris Kolpackov <bosk>
Group Member
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.

Paul D. Smith <psmith>
Group administrator
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

Anonymous
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.

Boris Kolpackov <bosk>
Group Member
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.

Paul D. Smith <psmith>
Group administrator
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.

Boris Kolpackov <bosk>
Group Member
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.

Chris Sutcliffe <ironhead>
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.

Paul D. Smith <psmith>
Group administrator
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.

Chris Sutcliffe <ironhead>
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.

Chris Sutcliffe <ironhead>

 

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

Attach Files:
   
   
Comment:
   

Attached Files
file #11099:  make_rule_issue.tar.gz added by ironhead (7KiB - 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
  • -email is unavailable- added by psmith (Posted a comment)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 3 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2009-06-10 psmith StatusNone Duplicate
        Open/ClosedOpen Closed
    2006-10-29 ironhead Attached File- Added make_rule_issue.tar.gz, #11099

    Back to the top

    Powered by Savane 3.13-d3ae.
    Corresponding source code