Re: [bug #33034] "Makefile:23: *** mixed implicit and normal rules. Stop." for Linux kernel out of source builds

[Paul Smith]

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.