[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20070110083445.31b79bab.khali@linux-fr.org>
Date: Wed, 10 Jan 2007 08:34:45 +0100
From: Jean Delvare <khali@...ux-fr.org>
To: Luca Tettamanti <kronos.it@...il.com>
Cc: Sam Ravnborg <sam@...nborg.org>,
Kai Germaschewski <kai@...maschewski.name>,
linux-kernel@...r.kernel.org
Subject: Re: .version keeps being updated
Hi Luca,
On Tue, 9 Jan 2007 22:55:27 +0100, Luca Tettamanti wrote:
> Jean Delvare <khali@...ux-fr.org> ha scritto:
> > Since 2.6.20-rc1 or so, running "make" always builds a new kernel with
> > an incremented version number, whether there has actually been any
> > change done to the code or configuration or not. This increases the
> > build time quite a bit.
> >
> > I've tracked it down to include/linux/compile.h always being updated,
> > and this is because .version is updated. I couldn't find what is
> > causing .version to be updated each time though. Can anybody help
> > there? Was this change made on purpose or is this a bug which we should
> > fix?
>
> kronos:~/src/linux-2.6.git$ cat ../linux-build-git/include/linux/compile.h
> /* This file is auto generated, version 14 */
> /* SMP PREEMPT */
> #define UTS_MACHINE "i386"
> #define UTS_VERSION "#14 SMP PREEMPT Tue Jan 9 22:45:18 CET 2007"
> #define LINUX_COMPILE_TIME "22:45:18"
> #define LINUX_COMPILE_BY "kronos"
> #define LINUX_COMPILE_HOST "dreamland.darkstar.lan"
> #define LINUX_COMPILE_DOMAIN "darkstar.lan"
> #define LINUX_COMPILER "gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-20)"
>
> LINUX_COMPILE_TIME and UTS_VERSION differs at each rebuild. UTS_VERSION
> is responsible of rebuilding fs/proc/proc_misc.o; init/main.o uses just
> about everything, init/version.o requires UTS_VERSION.
That's not quite true, LINUX_COMPILE_TIME and UTS_VERSION are
explicitely excluded from the comparison when checking whether
linux/compile.h changed. This is done in scripts/mkcompile_h, and I
believe this part works properly. This script wasn't modified recently.
> I don't think it's a regression from earlier kernels though, is it?
It definitely is, which is why I am reporting it and am asking for it
to be fixed. I isolated the two responsible commits elsewhere in the
thread.
Thanks,
--
Jean Delvare
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists