i don't agree and i see a possible attack

i'm tryign to compile gcc4 with glibc2.11 and seeing Makefile damage

you made comments impact upon linux, compatibility, does not matter

you then say "all past Makefiles should be edited by everyone but me to fit my new rules upon linux users: though past Makefiles had compiled correctly".  you made not of errors but obviously they are not material (or proved) since things did make.

however i see in your ChangeLog continual "fixes" the bulk of which SEEK WINDOWS32 compatibility.  so you are cross testimony.  you've made uploads over years seeking "compatibility" with a pay product getting grant money and gov money as well as consumer money.

but your editing a unix, GPL, made in america product (and public domain to americans not necessarily otherwise), allowing changes from overseas, and appear to be a Windows32 sided programmer

certainly that's an argument for conflict of interest under the circumstances.

-------------------------
the manual/ directory, a .po foreign affair maybe since i'm avoiding gettext up to core to see how it goes (C locale is a bit smaller spedier and more reliable from my standpoint)

make[2]: Leaving directory `/usr/src/glibc-2.11.2/wctype'

make  subdir=manual -C manual ..=../ subdir_lib
make[2]: Entering directory `/usr/src/glibc-2.11.2/manual'
Makefile:235: * mixed implicit and normal rules.  Stop.
make[2]: Leaving directory `/usr/src/glibc-2.11.2/manual'
make[1]: * [manual/subdir_lib] Error 2
make[1]: Leaving directory `/usr/src/glibc-2.11.2'
make: * [all] Error 2

i'm sure many foreign contributors have done good.  however it's ever more present that many are seekign toils and delays and IP "phone home" attacks integrated into linux (and hard to get out, deep in) - as well as windows hacks for people i wouldnt bet much are actually using linux to any extent.

-----------------------
i think i am up to say 200 work arounds now - maybe 300 including X11 - so far

and it gets to a ferver: it was not this broken before.  for example: X11R7.6 compiles quickly; download build install and run in < 1 hr.  download X11R7 tarball: and internet full of questions and complaints.  having submitted patches i'm absolutely sure i was fixing tampering, things that worked that were years later hacked to not work (ie, XV, there is no doubt)

obstructionism is certainly taking place in the gcc toolchain

and i know many people are from colleges (paid) or running webesites and or (california) 401c's getting grant money

the unix gnu linux products are public domain and some rely on them for business

this business of "anybody hack, if it dies it's more profit for the sellers" has got to stop

sellers of gov products copy lefted made in the past (usa) and getting grant money today over printed and inflated: that's not what i call owners.

!!!!!!!!!!!!!!!!!!!!!!

call it a rant i dont care what you think.  i find the "agreeability" and attacks against against those who dont agree and protest incompatible changes and sofware that phones home or forces itself in unix

i find that to be exactly part of why there are so many obstructions that there are currently

for one thing - whoever is hording KEYS: IP attacks and blacklists any who disagree is what i find

It's great to hear that such a simple fix addresses this regression.

As soon as this patch goes in, I'll follow up to the Debian bug about getting the patch backported, which should allow closing that bug and moving make from experimental to sid (and subsequently uploading 4.00).

> That's disappointing.

I've already explained why.  Makefile syntax, unlike the C ABI where you can always just define a new function, is not inherently extensible except in very limited ways, and I'm not interested in creating ever more obscure syntactical aberrations and/or adding tons of special backward-compatibility flags with their attendant headaches.  In my opinion makefiles already have more than enough syntactical foibles.  Take a look through the actual backward-compatibility issues raised in the NEWS file.

Of course, this is open source so you're free to provide a version of GNU make that does provide these types of options for backward compatibility, if you feel it's that important.

My opinion on backward-compat is that we make an effort to avoid backward-incompatibilities and try to ensure they have the smallest possible impact.  This change would likely have never been noticed if it hadn't affected Linux, and it would not be a big deal (only 3 files needed to be changed) except so many people apparently want to build old versions of the kernel.  How many people go back and build OpenOffice 1.0 on their brand new Ubuntu 14.04 systems, and so would care if the OpenOffice 1.0 makefiles no longer worked with GNU make 4.0?

If you cannot change your makefiles to avoid the backward-compat issues, you can always keep multiple versions of GNU make.  Unlike other tools like Java, GCC, etc. make is a single, simple executable that can be placed anywhere you want and named anything you want, and it will continue to work just fine.  Take two, they're small!

> I'm curious what you infer that from.

Two things from the manual: first the description of pattern rules explicitly describe what happens if you include a non-pattern prerequisite, but says nothing about allowing a non-pattern target.  Second GNU make lists the different types of lines in a makefile and none of those allows a mash-up of implicit and explicit rules like this.

And two things from experience: if you write "foo bar%:" it works, but if you write "bar% foo:" it fails with an error.  Also if you add a pattern prerequisite "foo bar% : baz%" that also fails to work (the target 'baz%', literally, is considered a prerequisite of the target 'foo').  Certainly any syntactical rules THAT obscure WOULD be mentioned explicitly in the manual, if this were intended to be a supported feature.

I admit I didn't understand the frustration level with this change.  The Linux kernel was the only package that ever reported any real issues, and there were (by my count) a total of three patches (all minor) over the span of a couple of months after the 3.82 release in 2010 to fix those problems.

The release-critical bug in Debian is, IMO, completely unjustified (and I didn't know about it anyway).  That bug should (a) not be release-critical, and (b) should be filed against the Linux kernel headers package, not GNU make.

If it turns out that simply changing the fatal() to an error() is sufficient to resolve this, I'm willing to make that change (I won't add a flag for it; the message will simply say the syntax is unsupported and should be updated).

HOWEVER, I'm not willing to guarantee that this syntax will continue to be supported going forward.  GNU make is not the kernel, and I reject attempts to impose the development ethos of the kernel on GNU make.  The syntax of makefiles is so free-form that virtually any enhancement that is made will be a backward-compatibility issue and I'm simply not willing to commit to that kind of restriction.  The kernel can always just introduce a different function name with new semantics--not so for makefiles.  If people need that level of backward-compatibility I recommend they simply keep around multiple versions of GNU make to support older code; make's installation is trivial, just the one program with no extra support files, and even after renaming it works flawlessly.

In this particular case I expect that even if the syntax still can be made to work now, when we support the ability to define explicit rules with multiple targets generated from a single recipe invocation, this syntax might not survive.  The fact is that this usage IS illegal according to the documentation (it may not be explicitly proscribed but writing down all the things that are NOT legal is an impossibility--it's easily, IMO, inferrable that the syntax is not intended to be valid).

I am not willing, at this point, to embrace the idea of "fixing" it so this syntax works fully and making it legal.  In my opinion it will be simply too confusing and difficult to manage all the edge cases around trying to combine two (or more, in the future) different rule models into a single statement.  I'm willing to look at any proposals someone has, but I warn you I'll be extremely skeptical.  I just don't think it's that big of a deal to write the rules separately, so any proposal will have to be VERY compelling to justify the complexity given the trivial alternative.

Yes, I realize it's a bit of a wing and a prayer but from the git log it looks like this fix got into the same commit as a rewrite of major sections of read.c. Without reading and thinking through all of it, I figured there was a chance that adding the fatal error had been the only thing done for this particular fix.

I'm uploading a patch that adds an --allow-mixed-rules option which converts the fatal error to a warning. This is the only testing it's been subjected to:

% cat Makefile
all %.o:
        @echo Making "$@"

% make-4.0
Makefile:1: * mixed implicit and normal rules.  Stop.

% make-4.0 --allow-mixed-rules
Makefile:1: warning: mixed implicit and normal rules
Making all

I don't claim to understand all the logic in read.c but from a quick examination of the git log this seemed to have a good chance of being all that's required. I'm not in a position to test it thoroughly at this time.


(file #29357)

>  Yes, formally it's not, but really, what's the chance a trivial one-line change to the top-level makefile will actually break your driver? :)

It's actually several non-trivial multi-line changes to various makefiles in the Linux source tree.  Look through the kernel's git history for "3.82" and you'll find several commits worth of makefile changes working around the "mixed implicit and normal rules" regression.

And in any case, having to apply any patches while digging back in the source tree is painful.

Re comment #5:

GCC is exceptionally careful about introducing backward-incompatible changes that break existing codebases, to the point where it provides options like -fpermissive to help older code continue to build.  As long as you don't blindly use options like -Werror, GCC generally doesn't break older codebases, for exactly this reason.  The rare times it has, notably the time that led to the introduction of the -fno-delete-null-pointer-checks option now used in the Linux kernel and other projects, have been huge debacles that generated incredible pain in numerous projects.

On top of that, GCC's rare instances of making parsing more strict have generally either been for standards compliance or to introduce some new feature or optimization that depended on the stricter behavior.  The release notes for make 3.82 don't give any indication about why make no longer accepts pattern rules and explicit targets in the same rule, just that it doesn't.  What motivated this change, and what amazing enhancement to GNU make does it allow that would not be possible while retaining that behavior?

This backward-incompatibile change makes it impossible to build older versions of the Linux kernel with current make, which breaks features like "git bisect" (for tracking down a bug in a range of kernel versions down to a specific commit).  It means that, for years to come, users will need a copy of make-3.81 sitting around, and have to know to use that for building older software when they see that particular error message.  And this change is the reason why make 3.82 is still sitting in Debian experimental and won't go into unstable anytime soon.  (And all the amazing features of make 4.0 seem likely to sit in experimental for a long time for the same reason.)

Given all that, is there any fundamental reason why make couldn't support this behavior for backward compatibility, either by default, or at least with an option to turn on that backward compatibility?  In particular, would you consider merging a patch to that effect if someone else wrote it?


Re comment #7: Please do, that would be highly welcome.

In fairness, this is a special situation. I have the same problem as "tz", and I expect quite a few other people do too.

My company makes drivers. The corollary is that we keep dozens if not hundreds of entire Linux kernel source build trees going back 10 years or so in order to build drivers for them. The way Linux kernel drivers are built makes it necessary to use the kernel build system. Thus it's not sufficient for us to fix our own makefiles, or even that Linux kernels which came out in the last year are fixed themselves. As things stand, we'll be unable to upgrade from GNU make 3.81 until all pre-2010 kernels have drained out of our support matrix, which could easily be another 10 years. Of course we also have the option of going back and "fixing" the makefiles for each old kernel, but once you've changed 2.6.18-128.7.1 then it's no longer 2.6.18-128.7.1.

So I at least think this issue is different from other incompatibilities and worthy of special consideration. If the original fix was a complete rewrite of parsing then maybe that's the end of the story, but if it's just a little patch which could be switched at runtime, would it be possible to add a special target to control that switch? I might sign up for the work if you agree it's not an outrageous thing to support.

It would help if for the next version there was a backward compatibility switch - there are a lot of archived kernel source trees (and probably a lot of other projects) that this breaks.

It would also help if the error message noted it was a change (mixed ... no longer allowed as of 3.82), because it is very confusing to do a bunch of updates and find the old builds no longer work.

As workaround for coLinux can change the template scripts/mkmakefile.

* old:

%/: all
        @:

* new:

\$(all) %/: all
ifneq (\$(all),)
\$(all): all
       @:

See also the attached patch.


(file #23162)

A build of Linux kernel out of source got this error, if target name was give on command line. It gots this error:

Makefile:23: * mixed implicit and normal rules.  Stop.

The relevant lines in Makefile:
16: all := $(filter-out all Makefile,$(MAKECMDGOALS))
23: $(all) %/: all

Full example:
cd /tmp
wget http://www.kernel.org/pub/linux/kernel/v2.6/longterm/v2.6.33/linux-2.6.33.9.tar.bz2
tar xjf linux-2.6.33.9.tar.bz2
mkdir linux-2.6.33.9-build
cd linux-2.6.33.9
make O=../linux-2.6.33.9-build defconfig
cd ../linux-2.6.33.9-build
make vmlinux

If replacing the command "make vmlinux" with "make", then it works. But it is no workaround, because I need to call "make modules_install" later.