When building 2.6.20-rc2-mm1 with CHECK_HEADERS=y, the Makefile will
build the target "include/config/kernel.release" twice. The first time,
the CONFIG_LOCALVERSION [and any auto local version] will correctly be
appended. Then, when it builds the "headers_check" target, the Makefile
will build the "include/config/kernel.release" target again, dropping
the local version information. If you then do a "make
[modules_]install" in this tree, the install will use the second version
string w/o the localversion, installing modules in the wrong place and
kernel/initrd with wrong name, possibly overwriting desired copies of
the "2.6.20-rc2-mm1" kernel/modules.
[Aside: it also appears that several items, including the kernel
itself, get rebuilt during "make [modules_]install" after a successful
"make [all]". I think this is new behavior.]
This behavior appears to have been introduced by the patch:
build-compileh-earlier.patch
Sorry, no patch to propose. Simple workaround is just to omit header
checks.
Here's the results of some instrumentation that I added to the Makefile
showing the sequence of targets built and which dependents cause the
build:
-------------------
<first build of target OK>
generating include/config/kernel.release: 2.6.20-rc1-mm1+foo
KERNELVERSION = 2.6.20-rc1-mm1
localver-full = +foo
localver = +foo
localver-auto =
Target: include/linux/utsrelease.h
Target: prepare3
Target: prepare1
<but later, for headers check>
generating include/config/kernel.release: 2.6.20-rc1-mm1
KERNELVERSION = 2.6.20-rc1-mm1
localver-full =
localver =
localver-auto =
Target: include/linux/utsrelease.h
Target: headers_install
Target: headers_check
----------------------------
Regards,
Lee
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
