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
