When I’m compiling the kernel, it shows the message “kernel-4.9 is not clean, please run ‘make mrproper’”. After running the ‘make mrproper’ command, when I attempt to compile the kernel again, it gives an error indicating that the file ‘zconf.hash.c’ cannot be found.
Hi,
Can you please re-extract the kernel source code and try again?
I think you should run tegra_defconfig
before building any other things.
I just tested on 32.7.4 and it worked fine:
davey@dave-yu-nvidia-pc:/mnt/1T-HDD/BSP/r32.7.4/NEW/Linux_for_Tegra/source/public/kernel/kernel-4.9$ make ARCH=arm64 CROSS_COMPILE_AARCH64=~/l4t-gcc/7.3.1/bin/aarch64-linux-gnu- tegra_defconfig
HOSTCC scripts/basic/fixdep
HOSTCC scripts/kconfig/conf.o
SHIPPED scripts/kconfig/zconf.tab.c
SHIPPED scripts/kconfig/zconf.lex.c
SHIPPED scripts/kconfig/zconf.hash.c
HOSTCC scripts/kconfig/zconf.tab.o
HOSTLD scripts/kconfig/conf
#
# configuration written to .config
#
Just some ideas to consider, not in a particular order…
mrproper
gives a pristine kernel source relative to configuration. Configuring a kernel is actually multiple steps, and if there is any stale configuration, the logic does not work, so the build is telling you about that situation.
If, at the top of the kernel source you run “make mrproper
” (or, if this source is owned by root, and it probably should be, then “sudo make mrproper
”).
Generally speaking, it is a good idea if the pristine source, without any configuration, is owned by root, and everyone can read the source, but nobody else is allowed to write to it. One can then build as a regular user to an external location without fear of any configuration remaining in the original source code. When you specify the “O=/some/where
” option it moves all of the configuration and temporary output to that location (in that example, to “/some/where
”). Should you need to start over, if that location started as an empty temporary directory, you can just delete that entire directory, recreate it as empty, and try again. Or a dozen different people could build from that same source code and it work for all of them. A single developer could use a dozen different empty output locations with a different configuration to test in every single one of those locations. “O=/some/where
” is your friend! 😃
If you create a configuration with the “O=
” option, then it produces the .config
file there. Before deleting the “O=
” location you could save the .config
, recreate the empty directory, and put the .config
back…suddenly you have that configuration.
Configuration is both the initial “.config
” file produced by targets such as “make O=/some/where tegra_defconfig
”, plus a “propagation” of that config to various subdirectories. If you were to start with pristine source, “make O=/some/where tegra_defconfig
”, and then build the Image
target, everything would work. If you instead built modules
as the first target, then it would fail. This is because Image
results in propagating the configuration through the entire source tree, but modules
does not. If you were to build modules
without building Image
, then you could do this:
# From source. Only needed once if root has done this and is owned by root.
sudo make mrproper
# A temporary directory, not as sudo:
mkdir ~/kernel
make O=~/kernel tegra_defconfig
# menuconfig and nconfig are "dependency intelligent" editing tools, they both do the same thing.
make O=~/kernel nconfig
# Save your nconfig or menuconfig edits. Then, assuming we only build modules:
make O=~/kernel modules_prepare
make O=~/kernel modules
modules_prepare
is not needed if you already built Image
.
Some URLs regarding kernel configuration and build (there will be differences depending on cross compile versus native compile, but the concepts are valid in both cases; you can always ask more questions):
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.