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
