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
