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

 
 

bug #31002: make picks wrong pattern rule

Submitter:  Andreas Schwab <schwab>
Submitted:  Thu 09 Sep 2010 12:15:56 PM UTC
   
 
Severity:  3 - Normal Item Group:  Bug
Status:  Wont Fix Privacy:  Public
Assigned to:  None Open/Closed:  Closed
Component Version:  3.82 Operating System:  Any
Fixed Release:  None Triage Status:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Sun 25 Sep 2022 10:45:22 PM UTC, comment #9: 

The new behavior has been standard for 12+ years and most people seem to prefer it; I'm not going to revert this change.

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

* WARNING: Backward-incompatibility!
  The pattern-specific variables and pattern rules are now applied in the
  shortest stem first order instead of the definition order (variables
  and rules with the same stem length are still applied in the definition
  order). This produces the usually-desired behavior where more specific
  patterns are preferred. To detect this feature search for 'shortest-stem'
  in the .FEATURES special variable.


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>
Group 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 Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

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

    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 2 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2022-09-25 psmith StatusNone Wont Fix
        Open/ClosedOpen Closed

    Back to the top

    Powered by Savane 3.13-4448.
    Corresponding source code