bugmake - Bugs: bug #31002, make picks wrong pattern rule

 
 

bug #31002: make picks wrong pattern rule

Submitted by:  Andreas Schwab <schwab>
Submitted on:  Thu 09 Sep 2010 12:15:56 PM UTC  
 
Severity: 3 - NormalItem Group: Bug
Status: NonePrivacy: Public
Assigned to: NoneOpen/Closed: Open
Component Version: 3.82Operating System: Any
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 27 Oct 2010 08:47:41 AM UTC, comment #8:

My vote for reverting this change. Incomprehensible webs of legacy makefiles are indeed a major issue.

Reinier Post <r_p>
Mon 13 Sep 2010 11:55:40 AM UTC, comment #7:

I think we should move this to the make-alpha or bug-make lists. I don't think Savannah bug trackers are the right way to address the larger conceptual issues of when backward-compatibility breaks are OK and when they're not.

Paul D. Smith <psmith>
Project Administrator
Fri 10 Sep 2010 08:50:31 PM UTC, comment #6:

Roland, I think you overstate the seriousness of the problem. There are not many makefiles that both define multiple pattern rules and rely on their order for selection. 3.82 has been out for a few months now and glibc is the first such case (which, BTW, is easy to fix in a backwards-compatible way). To be fair, the glibc build system is pretty complex, perhaps the most complex of any widely-used package. If I remember correctly, the previous release of GNU make also broke its build (or was it GCC).

On the other hand, we need to be able to evolve GNU make so that it supports more complex build systems. This particular feature is meant to allow assembling pattern rules from multiple makefiles that don't necessarily know anything about each other. Prior to this release such assembly was pretty much impossible. I won't be surprised if at some point in the future glibc developers will make use of this feature.

Boris Kolpackov <bosk>
Project Member
Fri 10 Sep 2010 06:52:58 PM UTC, comment #5:

IMHO these dismally subtle incompatible changes in make semantics were an absolutely terrible idea. I'm quite dismayed that Paul has been so cavalier in breaking what was well-defined behavior in make for about two decades now. Imperfect as they may be, the semantics have been set for a long, long time. Changes like these will never have simple effects, always terribly subtle ones. In glibc, we have some real experts who can tease out the details as necessary--but even I have difficulty thinking through the ramifications of this change, and if anyone out there were comfortable with GNU make semantics, it ought to have been me. For other users dealing with complex webs of makefiles inherited in their projects, I have to think they will just suffer and despair.

Roland McGrath <roland>
Thu 09 Sep 2010 09:27:42 PM UTC, comment #4:

In this case GNU make 3.82 does exactly what it claims it will do. Unfortunately the expected (from glibc's perspective) behavior falls into that 0.01% of cases where the more qualified rule is not what needs to be selected.

The assumption here is that a more specialized rule should be preferred over a more general one. For example:

%.o: %.c; $(CC) -o $@ $<
%-pic.o: %.c; $(CC) -fPIC -o $@ $<

Here we want make to select the second rule when building foo-pic.o and the first rule when building foo.o.

Similar thing happens in your case: make looks for a rule to build rtld-memset.so and chooses a rule specific to building the 'rtld' kind of targets rather than any kind. The way to resolve this would be to add two more rules before the existing 'rtld-%' ones:

rtld-%.os: rtld-%.S
@echo $@: rtld-%os: rtld-%.S: $<
rtld-%.os: rtld-%.c
@echo $@: rtld-%os: rtld-%.c: $<

With this change I get

rtld-memset.os: rtld-%os: rtld-%.c: rtld-memset.c

with 3.82 and the old behavior with 3.81.

Boris Kolpackov <bosk>
Project Member
Thu 09 Sep 2010 03:18:56 PM UTC, comment #3:

Ah I see, because the pattern matches different parts of the stem. Good point. Let me discuss with Boris.

Paul D. Smith <psmith>
Project Administrator
Thu 09 Sep 2010 03:00:19 PM UTC, comment #2:

This is wrong. The third rule will be selected if rtld-memset.c does not exist.

Andreas Schwab <schwab>
Thu 09 Sep 2010 01:45:51 PM UTC, comment #1:

This is due to this change, from the NEWS file:

I'm assuming that your makefiles are more complex than this; can you explain in what situation this capability is used by glibc?

In the example you give here, for example, the last two rules will NEVER be chosen by GNU make 3.81 so you might as well just delete them. Then your makefile would work in both 3.81 and 3.82.

But maybe the glibc makefiles need both, and I'd like to understand why.

Paul D. Smith <psmith>
Project Administrator
Thu 09 Sep 2010 12:15:56 PM UTC, original submission:

$ cat Mafile
%.os: %.S
@echo $@: %.os: %.S: $<
%.os: %.c
@echo $@: %.os: %.c: $<
rtld-%.os: %.S
@echo $@: rtld-%os: %.S: $<
rtld-%.os: %.c
@echo $@: rtld-%os: %.c: $<

all: rtld-memset.os
$ touch rtld-memset.c memset.S

$ make --version | head -n1
GNU Make 3.81
$ make
rtld-memset.os: %.os: %.c: rtld-memset.c

$ rpm -q make | head -n1
GNU Make 3.82
$ make
rtld-memset.os: rtld-%os: %.S: memset.S

This breaks the glibc makefiles.

Andreas Schwab <schwab>

 

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

Attach File(s):
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by r_p (Posted a comment)
  • -unavailable- added by roland (Posted a comment)
  • -unavailable- added by bosk (Posted a comment)
  • -unavailable- added by psmith (Posted a comment)
  • -unavailable- added by schwab (Submitted the item)
  •  

    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):

     

     

    No Changes Have Been Made to This Item

    Back to the top


    Powered by Savane 3.1-cleanup