[Top][All Lists]

[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


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


> 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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]