Re: [regression ?] kbuild: fix building bzImage with CONFIG_TRIM_UNUSED_KSYMS enabled
From: Sergey Senozhatsky
Date: Sat Dec 10 2016 - 21:19:43 EST
On (12/10/16 16:04), Nicolas Pitre wrote:
> On Sat, 10 Dec 2016, Sergey Senozhatsky wrote:
> > so this will not install modules:
> > make prepare; make kernelrelease; make -j4; make prepare; make kernelrelease; make -j4 INSTALL_MOD_PATH=/tmp/MODULES modules_install
> > and this will:
> > make prepare; make kernelrelease; make -j4; make kernelrelease; make -j4 INSTALL_MOD_PATH=/tmp/MODULES modules_install
> Right. And this is because of this in the main Makefile:
> # Create temporary dir for module support files
> # clean it up only when building all modules
> cmd_crmodverdir = $(Q)mkdir -p $(MODVERDIR) \
> $(if $(KBUILD_MODULES),; rm -f $(MODVERDIR)/*)
> The list of modules to install is created from files found in
> $(MODVERDIR)/. This is cleared when KBUILD_MODULES is set. Oddly
> enough, KBUILD_MODULES is _not_ globally set when building individual
> modules probably not to clear MODVERDIR. This requires explicit override
> like in this rule:
> %.ko: prepare scripts FORCE
> $(Q)$(MAKE) KBUILD_MODULES=$(if $(CONFIG_MODULES),1) \
> $(build)=$(build-dir) $(@:.ko=.o)
> One could wonder why $(cmd_crmodverdir) is executed again here given
> that it is already part of the "prepare" target, but that's an
> orthogonal issue.
> Another question is whether or not KBUILD_MODULES is the right criteria
> for clearing MODVERDIR. My first reaction is to say it is not, but I
> can't come up with anything better at the moment.
> And KBUILD_MODULES must be set for any target that results in
> vmlinux being built (and there are many of them including arch specific)
> whenever CONFIG_TRIM_UNUSED_KSYMS=y. Can this be enforced elsewhere in
> the Makefile, like in the recipe for $(vmlinux-dirs)? I don't know. IMHO
> this will only make things even less pretty than they are now.
> In the mean time, though, I'm wondering why you have to do "make
> prepare" twice, or even at all.
well, not that I really wanted to execute it twice, it just was at
the beginning of the build/packaging script that I touched some 6-7
> So, given all the above considerations, would it be possible for you to
> "fix" your build script instead?