[bug #33034] Makefile:23: *** mixed implicit and normal rules. Stop. for Linux kernel out of source builds
Follow-up Comment #22, bug #33034 (project make): 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 ___ Reply to this item at: http://savannah.gnu.org/bugs/?33034 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: [bug #33034] Makefile:23: *** mixed implicit and normal rules. Stop. for Linux kernel out of source builds
On Sun, Oct 20, 2013 at 11:58:00PM -0400, Paul Smith wrote: On Sun, 2013-10-20 at 20:15 -0700, David Boyce wrote: Paul. Thank you very much! This means I'll be able to make professional use the many features and bugfixes which have arrived post-3.81 at some point. Given the flurry of other fit-and-finish fixes lately, would it be safe to assume there will be a 4.01 or equivalent upcoming in the foreseeable future? Yes, before too long. I don't plan on any major features in the next release, just cleanup and bug fixing. I don't plan on a release right away (like this month) though. Not a problem; it should be an easy patch to backport. I have to admit I still just don't understand the problem here. Surely no one is building kernels that old (pre-2.6.34) without any patches at all applied; that sounds inconceivably insecure. Why not just add one more patch that changes the 3 places (at most) in the makefiles that have this problem to the suite of patches that are already applied to those old kernels when you build them? It seems insane to me to avoid updating tools merely because of a few lines of makefile change in kernels that are almost 4 years old. When doing archaeology on old kernels via git, you don't normally apply *any* patches if you can help it, because they're a pain to keep re-applying to each kernel you want to examine. Anyway. It will work for now, apparently. Thanks! - Josh Triplett ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
[bug #33034] Makefile:23: *** mixed implicit and normal rules. Stop. for Linux kernel out of source builds
Update of bug #33034 (project make): Status: Not A Bug = Fixed Assigned to:None = psmith Fixed Release:None = SCM ___ Follow-up Comment #21: I have pushed a change to the Git repository. ___ Reply to this item at: http://savannah.gnu.org/bugs/?33034 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: [bug #33034] Makefile:23: *** mixed implicit and normal rules. Stop. for Linux kernel out of source builds
Paul. Thank you very much! This means I'll be able to make professional use the many features and bugfixes which have arrived post-3.81 at some point. Given the flurry of other fit-and-finish fixes lately, would it be safe to assume there will be a 4.01 or equivalent upcoming in the foreseeable future? David On Sun, Oct 20, 2013 at 10:09 AM, Paul D. Smith invalid.nore...@gnu.org wrote: Update of bug #33034 (project make): Status: Not A Bug = Fixed Assigned to:None = psmith Fixed Release:None = SCM ___ Follow-up Comment #21: I have pushed a change to the Git repository. ___ Reply to this item at: http://savannah.gnu.org/bugs/?33034 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: [bug #33034] Makefile:23: *** mixed implicit and normal rules. Stop. for Linux kernel out of source builds
On Sun, 2013-10-20 at 20:15 -0700, David Boyce wrote: Paul. Thank you very much! This means I'll be able to make professional use the many features and bugfixes which have arrived post-3.81 at some point. Given the flurry of other fit-and-finish fixes lately, would it be safe to assume there will be a 4.01 or equivalent upcoming in the foreseeable future? Yes, before too long. I don't plan on any major features in the next release, just cleanup and bug fixing. I don't plan on a release right away (like this month) though. I have to admit I still just don't understand the problem here. Surely no one is building kernels that old (pre-2.6.34) without any patches at all applied; that sounds inconceivably insecure. Why not just add one more patch that changes the 3 places (at most) in the makefiles that have this problem to the suite of patches that are already applied to those old kernels when you build them? It seems insane to me to avoid updating tools merely because of a few lines of makefile change in kernels that are almost 4 years old. Anyway. It will work for now, apparently. ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
[bug #33034] Makefile:23: *** mixed implicit and normal rules. Stop. for Linux kernel out of source builds
Follow-up Comment #15, bug #33034 (project make): David Boyce wrote: I agree with some of your points but there was a bit of cherrypicking involved in the quoting: ... really, what's the chance a trivial one-line change to the top-level makefile will actually break your driver? I'm not sure you realize the scale here. It's not a change to just the top-level makefile, the pattern is repeated in a number of makefiles. I was just going with was was said in the bug report. The workaround in comment #2 is indeed a trivial one-line change. If that's not all, this wasn't mentioned before, sorry. To me this seems a great example of bad bug reporting: - The original report and workaround make it look like a trivial issue. - The explanation for the change (quoted in comment #3) was ignored (see comment #5). - The whole issue was ignored for 2 years, just until the next major release which is just about the worst time to reinstate old behaviour for bugward compatibility. A quick find shows 1360 makefiles in a typical Linux (2.6.36) kernel Fun fact: A quick find shows over 50 files on my hard disk! (Which is just as relevant to the issue; according to the git history search Josh recommended, it seems to be 3, in words three, affected Makefiles, two of them in arch, so possibly not even relevant to you. Over-inflating numbers doesn't help.) At least in our case, because these are so large and (supposed to be) unchanging we haven't stored them in version control; they're in flat file space aka NFS. With this many files to fix it would be necessary to write a program which could reliably find all mixed rule lines and fix them right the first time. The fact that they're not version controlled makes the stakes higher. Though I see that it can be a problem for you, I think higher stakes is another exaggeration. It can't be too difficult to back up the changed makefiles, even without source control. I don't suppose Paul would accept a patch that just reinstates the old behaviour without fixing it.) Of course not, that's been made quite clear and it makes sense. But what you left out from my comment was the question of whether it could be optionally unfixed at runtime. We all get that the old behavior was broken, but this happens to be a case where preserving bug-for-bug compatibility is important to many users. That's not so clear to me. It ought to be possible to really fix the problem, i.e. accept mixed rules without the bugs in the original (unintended) feature. Of course, this is more work than just suppressing a (well justified) error message. If you or someone does this properly, I suppose Paul wouldn't object. I've long accepted that Debian isn't useful to me out of the box... I don't think this point was specific to Debian; rather, it was intended as an illustration of the fact that 3+ years after 3.82 was released it still hasn't gained widespread acceptance. Many environments are sticking with 3.81 and I suspect this is one of the factors. I thought other distributions had long moved past the affected versions of Linux and all the other unnamed numerous affected software. (Mind you, I sometimes like Debian's conservative release schedule, but it's pretty unique.) ___ Reply to this item at: http://savannah.gnu.org/bugs/?33034 ___ Nachricht gesendet von/durch Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
[bug #33034] Makefile:23: *** mixed implicit and normal rules. Stop. for Linux kernel out of source builds
Follow-up Comment #16, bug #33034 (project make): 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. ___ Reply to this item at: http://savannah.gnu.org/bugs/?33034 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
[bug #33034] Makefile:23: *** mixed implicit and normal rules. Stop. for Linux kernel out of source builds
Follow-up Comment #17, bug #33034 (project 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). Thank you. GNU make is not the kernel, and I reject attempts to impose the development ethos of the kernel on GNU make. That's disappointing. Personally, when holding up software as the model of backward compatibility, I usually point to debhelper, which still supports packages written for the very first version. it's easily, IMO, inferrable that the syntax is not intended to be valid I'm curious what you infer that from. I haven't found anything to that effect outside of the 3.82 release notes. That bug should (a) not be release-critical, and (b) should be filed against the Linux kernel headers package, not GNU make. The kernel has already been fixed. The RC bug on Make is for introducing a regression in Makefile parsing. ___ Reply to this item at: http://savannah.gnu.org/bugs/?33034 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
[bug #33034] Makefile:23: *** mixed implicit and normal rules. Stop. for Linux kernel out of source builds
Follow-up Comment #12, bug #33034 (project make): 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) ___ Additional Item Attachment: File name: allow.patchSize:2 KB ___ Reply to this item at: http://savannah.gnu.org/bugs/?33034 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
[bug #33034] Makefile:23: *** mixed implicit and normal rules. Stop. for Linux kernel out of source builds
Follow-up Comment #14, bug #33034 (project make): 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. ___ Reply to this item at: http://savannah.gnu.org/bugs/?33034 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: [bug #33034] Makefile:23: *** mixed implicit and normal rules. Stop. for Linux kernel out of source builds
On Thu, 2011-11-10 at 14:51 -0500, tz wrote: On Nov 10, 2011 2:32 PM, Paul Smith psm...@gnu.org wrote: On Thu, 2011-11-10 at 10:36 -0500, tz wrote: You don't need to cross-compile: you can compile natively. What you can't do is rely on your upstream vendor to provide you the toolchain you are going to use. You need to build it yourself, using known versions, and install the results in a separate location (not your distro's /usr/bin). That doesn't work if you don't have space on the embedded device. Some don't have resources to network mount, and builds take days (literally). ??? So OK, you ARE using a cross-compiler. I thought you said earlier that you didn't want to. Anyway it doesn't matter whether you're building natively or cross; what matters is that you use an archived, known version of your toolchain to build your target code and not whatever version of the toolchain is delivered with your desktop du jour. ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: [bug #33034] Makefile:23: *** mixed implicit and normal rules. Stop. for Linux kernel out of source builds
Judging from the outpouring of support I received when I made the same suggestion/offer :-( I'm unsurprised at seeing no public response to yours either. But disappointed. I agree that this is a real problem which does not seem to resonate with those not directly affected by it. I think the best approach is probably to follow the CVS commit trail, find the commit which fixed the original bug, and see if it can be made conditional on a special target .ALLOW_MIXED_RULES: or something. This could then be requested without any makefile modification by something like export MAKEFLAGS=--eval .ALLOW_MIXED_RULES: Alternatively, if Paul would allow it, the test could be directly for an EV. The question in my mind, which would probably be answerable by finding the commit, is whether the original fix was a simple patch which could be easily conditionalized or a part of a large-scale parser rewrite. David On Thu, Nov 3, 2011 at 11:54 PM, Jonathan Nieder invalid.nore...@gnu.org wrote: Follow-up Comment #7, bug #33034 (project make): Just for the record, I have been looking for a spare moment to come up with a patch to fix this compatibility problem (which affects many projects other than the Linux kernel, too). If that's a bad idea for some reason, please feel free to let me know why. :) And if anyone else starts before I do, I won't mind --- on the contrary, I'll be very happy. ___ Reply to this item at: http://savannah.gnu.org/bugs/?33034 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: [bug #33034] Makefile:23: *** mixed implicit and normal rules. Stop. for Linux kernel out of source builds
I doubt there is much reason to expect public support. Remember the response to my request: I really am not interested in changing all the error messages to give details about which version of GNU make that error was introduced, and I'm also not interested in adding flags to every version of GNU make which allows for backward-compatibility with older versions. That seems completely unwieldy from a development and maintenance point of view. Unfortunately, in the embedded world, not everything is updated constantly. Even the desktop is not updated weekly. ARM is still at Fedora 12, though 16 was just released. I don't and won't have an updated kernel tree that works unless I find some way to recompile everything, and the huge, complex, slow, and obscure autotools are often broken for cross compiling much beyond GCC itself and associated tools. I doubt the entire tree in the FSF repository can be properly cross-compiled. Debian has taken to arrays of the various processors so they can go native. This was a corner case that probably shouldn't have worked, but it did, and a very large number of linux kernel versions require that behavior, so they can't be built with the current Make, and give no indication of anything that changed. If it was some obscure package, I would agree. If it was some long documented very specifically wrong usage that the kernel developers refused to fix as soon as it was reported I would also agree. I wasn't asking to change all the error messages or for flags for every version of GNU make, but only this one. make --accept-bad-old-linux-makefiles or a SINGLE message for this case would suffice. There are already dozens of options that subtly change the behavior or even ignored for compatibility and messages given when things are wrong in the makefile. You won't eliminate those because they would break too many things or are useful for debugging the makefile. Perhaps a script could be written to modify the bad lines in the makefile automatically. That would also fix things. On Thu, Nov 10, 2011 at 9:39 AM, David Boyce david.s.bo...@gmail.comwrote: Judging from the outpouring of support I received when I made the same suggestion/offer :-( I'm unsurprised at seeing no public response to yours either. But disappointed. I agree that this is a real problem which does not seem to resonate with those not directly affected by it. ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: [bug #33034] Makefile:23: *** mixed implicit and normal rules. Stop. for Linux kernel out of source builds
David Boyce wrote: I'm unsurprised at seeing no public response to yours either. But disappointed. I'm not disappointed. Paul doesn't work for me so there is no obligation for him to write patches or design specs supporting my use cases. And neverthless, so far I've had no reason to be unhappy with what he does. I think the best approach is probably to follow the CVS commit trail, find the commit which fixed the original bug, and Yes, that's probably good advice. Cheers, Jonathan ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: [bug #33034] Makefile:23: *** mixed implicit and normal rules. Stop. for Linux kernel out of source builds
On Thu, 2011-11-10 at 10:36 -0500, tz wrote: Unfortunately, in the embedded world, not everything is updated constantly. Even the desktop is not updated weekly. ARM is still at Fedora 12, though 16 was just released. I don't and won't have an updated kernel tree that works unless I find some way to recompile everything, and the huge, complex, slow, and obscure autotools are often broken for cross compiling much beyond GCC itself and associated tools. I doubt the entire tree in the FSF repository can be properly cross-compiled. I've done embedded development work for many years; in fact much of my work even today involves embedded targets. I understand the issues involved with being forced to work with old software, cross-compiled software, minimally supported targets, etc. However no argument I've seen so far has convinced me that this backward-compatibility mode is necessary. Using whatever native toolchain you have installed on whatever distribution you happen to be using this week to build your target platform is just asking for pain everlasting. No sane and reliable environment can work like this. Today you're having an issue with make, but tomorrow it will be a change in GCC, or binutils, or whatever... then what? Will you be asking GCC to add a special flag to switch back to old behavior just to support older Linux kernels? Not going to happen. Why is this different? In every environment I work on I always have a completely separate toolchain, including the compiler, binutils, flex, yacc, gdb, even things like fakeroot, to build my software... and make is unquestionably part of the toolchain. And of course, even if we were to make this change and release a new GNU make today you would STILL have this problem in any existing environments... you'd need to deploy a custom version of make and use that instead anyway. I just cannot see a single significant advantage to this... I'm still open to hearing one though. I doubt the entire tree in the FSF repository can be properly cross-compiled. Debian has taken to arrays of the various processors so they can go native. You don't need to cross-compile: you can compile natively. What you can't do is rely on your upstream vendor to provide you the toolchain you are going to use. You need to build it yourself, using known versions, and install the results in a separate location (not your distro's /usr/bin). I wasn't asking to change all the error messages or for flags for every version of GNU make, but only this one. Yes, that's what everyone says... about their particular issue. The reality is that the change needed in the Linux makefiles to avoid this problem is so trivial we could have created patches for every prior version of the kernel you need in less time than it's taken us to have this conversation. ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: [bug #33034] Makefile:23: *** mixed implicit and normal rules. Stop. for Linux kernel out of source builds
Paul Smith wrote: Today you're having an issue with make, but tomorrow it will be a change in GCC, or binutils, or whatever... then what? Will you be asking GCC to add a special flag to switch back to old behavior just to support older Linux kernels? Not going to happen. Why is this different? Just for the record: no, GCC and binutils have a pretty good track record for compatibility, as far as big users like the kernel (and glibc, except that glibc and binutils versions tend to be tied for obvious reasons) go. The last major problem I remember seeing was http://bugs.debian.org/620448, which offers a compatibility switch. But I think it's up to the people complaining to offer a patch. And I think it's perfectly reasonable for you to say no if such a patch is too invasive or ugly. And of course, even if we were to make this change and release a new GNU make today you would STILL have this problem in any existing environments... you'd need to deploy a custom version of make and use that instead anyway. Nah. Debian at least has been holding back on moving to 3.82, mostly for this reason. ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: [bug #33034] Makefile:23: *** mixed implicit and normal rules. Stop. for Linux kernel out of source builds
On Nov 10, 2011 2:32 PM, Paul Smith psm...@gnu.org wrote: On Thu, 2011-11-10 at 10:36 -0500, tz wrote: I doubt the entire tree in the FSF repository can be properly cross-compiled. Debian has taken to arrays of the various processors so they can go native. You don't need to cross-compile: you can compile natively. What you can't do is rely on your upstream vendor to provide you the toolchain you are going to use. You need to build it yourself, using known versions, and install the results in a separate location (not your distro's /usr/bin). That doesn't work if you don't have space on the embedded device. Some don't have resources to network mount, and builds take days (literally). I can build cross-toolchains, but then often ./configure fails even if I specify host, target, etc. right. There are usually a bunch of libs, few of which build right either. Maybe you have a MIPS system that has a full distro, lots of memory, and is fast. I don't. ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
[bug #33034] Makefile:23: *** mixed implicit and normal rules. Stop. for Linux kernel out of source builds
Follow-up Comment #7, bug #33034 (project make): Just for the record, I have been looking for a spare moment to come up with a patch to fix this compatibility problem (which affects many projects other than the Linux kernel, too). If that's a bad idea for some reason, please feel free to let me know why. :) And if anyone else starts before I do, I won't mind --- on the contrary, I'll be very happy. ___ Reply to this item at: http://savannah.gnu.org/bugs/?33034 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
[bug #33034] Makefile:23: *** mixed implicit and normal rules. Stop. for Linux kernel out of source builds
Follow-up Comment #4, bug #33034 (project make): 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. ___ Reply to this item at: http://savannah.gnu.org/bugs/?33034 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
[bug #33034] Makefile:23: *** mixed implicit and normal rules. Stop. for Linux kernel out of source builds
Follow-up Comment #5, bug #33034 (project make): I'm not trying to be flip, but what do you do when you upgrade to a new version of the compiler and older code no longer builds correctly due to more stringent requirements? I see this in code all the time (not GNU make) with new versions of GCC for example. I really am not interested in changing all the error messages to give details about which version of GNU make that error was introduced, and I'm also not interested in adding flags to every version of GNU make which allows for backward-compatibility with older versions. That seems completely unwieldy from a development and maintenance point of view. ___ Reply to this item at: http://savannah.gnu.org/bugs/?33034 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
[bug #33034] Makefile:23: *** mixed implicit and normal rules. Stop. for Linux kernel out of source builds
Follow-up Comment #6, bug #33034 (project make): 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. ___ Reply to this item at: http://savannah.gnu.org/bugs/?33034 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: [bug #33034] Makefile:23: *** mixed implicit and normal rules. Stop. for Linux kernel out of source builds
On Fri, May 20, 2011 at 12:46 PM, David Boyce invalid.nore...@gnu.org wrote: 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. Since gcc has changed many time across those years in ways that have affected the Linux kernel build (the move to __attribute__((always_inline)) comes to mind), don't you already have to track a build environment for each kernel version? I haven't tried, but I believe that the current version of gcc will *not* build a 10 year old kernel, or at least not a _working_ one. For that you need a 10 year old gcc, or at least something much closer to it in time. Well, the same applies to GNU make and may apply to other build tools (binutils/as/ld?). Whatever system you use for tracking gcc releases should be applied to all the tools in the kernel build environment. Philip Guenther ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
[bug #33034] Makefile:23: *** mixed implicit and normal rules. Stop. for Linux kernel out of source builds
Update of bug #33034 (project make): Status:None = Not A Bug Open/Closed:Open = Closed ___ Follow-up Comment #3: This is an intentional change. See the GNU make NEWS file: * WARNING: Backward-incompatibility! In previous versions of make it was acceptable to list one or more explicit targets followed by one or more pattern targets in the same rule and it worked as expected. However, this was not documented as acceptable and if you listed any explicit targets AFTER the pattern targets, the entire rule would be mis-parsed. This release removes this ability completely: make will generate an error message if you mix explicit and pattern targets in the same rule. You must split these rules into two rules: one for the pattern and one for the explicit targets. The Linux kernel source has already been modified in this way (in newer kernels). ___ Reply to this item at: http://savannah.gnu.org/bugs/?33034 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
[bug #33034] Makefile:23: *** mixed implicit and normal rules. Stop. for Linux kernel out of source builds
Follow-up Comment #2, bug #33034 (project make): 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) ___ Additional Item Attachment: File name: make-3.82-mkmakefile.patch Size:0 KB ___ Reply to this item at: http://savannah.gnu.org/bugs/?33034 ___ Nachricht geschickt von/durch Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
[bug #33034] Makefile:23: *** mixed implicit and normal rules. Stop. for Linux kernel out of source builds
Follow-up Comment #1, bug #33034 (project make): Sorry. forgotten to login while creating this bug. The bug was original reported by a coLinux user: http://article.gmane.org/gmane.linux.colinux.general/5230 Make 3.81 works. ___ Reply to this item at: http://savannah.gnu.org/bugs/?33034 ___ Nachricht geschickt von/durch Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
[bug #33034] Makefile:23: *** mixed implicit and normal rules. Stop. for Linux kernel out of source builds
URL: http://savannah.gnu.org/bugs/?33034 Summary: Makefile:23: *** mixed implicit and normal rules. Stop. for Linux kernel out of source builds Project: make Submitted by: None Submitted on: Sa 09 Apr 2011 10:42:24 UTC Severity: 3 - Normal Item Group: Bug Status: None Privacy: Public Assigned to: None Open/Closed: Open Discussion Lock: Any Component Version: 3.82 Operating System: POSIX-Based Fixed Release: None Triage Status: None ___ Details: 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. ___ File Attachments: --- Date: Sa 09 Apr 2011 10:42:25 UTC Name: Makefile Size: 523B By: None Linux kernel Makefile from make defconfig in build directory http://savannah.gnu.org/bugs/download.php?file_id=23155 ___ Reply to this item at: http://savannah.gnu.org/bugs/?33034 ___ Nachricht geschickt von/durch Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
