[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Parallel building of Linux Kernel is broken
From: |
Masahiro Yamada |
Subject: |
Re: Parallel building of Linux Kernel is broken |
Date: |
Thu, 12 Jul 2018 13:55:51 +0900 |
Hi.
2018-07-12 13:37 GMT+09:00 Paul Smith <address@hidden>:
> On Thu, 2018-07-12 at 10:26 +0900, Masahiro Yamada wrote:
>> $ make -j8 defconfig all
>> HOSTCC scripts/basic/fixdep
>> HOSTCC scripts/kconfig/conf.o
>> YACC scripts/kconfig/zconf.tab.c
>> LEX scripts/kconfig/zconf.lex.c
>> HOSTCC scripts/kconfig/zconf.tab.o
>> HOSTLD scripts/kconfig/conf
>> *** Default configuration is based on 'x86_64_defconfig'
>> #
>> # configuration written to .config
>> #
>> scripts/kconfig/conf --syncconfig Kconfig
>> make[1]: warning: jobserver unavailable: using -j1. Add '+' to
>> parent
>> make rule.
>> SYSTBL arch/x86/include/generated/asm/syscalls_32.h
>
> Someone will need to investigate this further as the information we
> need has been elided. Is there a way to invoke the Linux kernel
> makefile with a "verbose" mode that doesn't use these shorthand outputs
> for commands but instead actually shows the commands that recipes ask
> make to invoke?
Please add V=1 to the build command, like this:
$ make -j8 V=1 defconfig all
It will emit _almost_ raw log.
> That's what we need to see; the actual command that
> was used to recursively invoke make.
Linux Makefile hides "Entering directory ..." messages.
If you want to see them,
please comment out the following line of the top Makefile.
MAKEFLAGS += --no-print-directory
Thanks,
> This warning means that a sub-make has been invoked but that the
> makefile invoking it didn't realize it was a sub-make: that was hidden
> from make by not using the $(MAKE) variable in the recipe.
>
> In that case, make recommends that the makefile rule be prefixed with
> the '+' character to tell make that the rule is a recursive invocation.
>
> Unless make realizes that the recipe it runs will invoke a sub-make, it
> can't properly prepare the environment for that sub-make.
>
> I'm somewhat surprised that the build was not seeing this error before,
> because it definitely was previously emitted: that error message has
> been around for a long time.
>
> As mentioned I'd need to see the actual command line invocation in
> order to understand why this might have happened.
>
--
Best Regards
Masahiro Yamada