From: Borislav Petkov <bp@alien8.de>
To: Masahiro Yamada <yamada.masahiro@socionext.com>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Michal Marek <michal.lkml@markovi.net>,
Linux Kbuild mailing list <linux-kbuild@vger.kernel.org>
Subject: Re: [PATCH] kbuild: Fail the build early when no lz4 present
Date: Thu, 11 Oct 2018 10:52:34 +0200 [thread overview]
Message-ID: <20181011085234.GA25435@zn.tnic> (raw)
In-Reply-To: <CAK7LNAT2KpYkn=hj=h1XmbMJRdtgCQ__xP0X+Rpwm3e_Xs1brQ@mail.gmail.com>
On Thu, Oct 11, 2018 at 01:26:23PM +0900, Masahiro Yamada wrote:
> So, the cause of the failure is clear enough
> from the build log.
Sure but it wasts unnecessary build cycles and appears only after all
the compilation units have been produced.
> It is weird to check only lz4c.
> If CONFIG_KERNEL_LZO is enabled, but lzop is not installed,
> I see this log
>
> LZO arch/x86/boot/compressed/vmlinux.bin.lzo
> /bin/sh: 1: lzop: not found
>
> It is still clear what to do, though.
Right, we should test for that too. Unless distros start installing it
by default. It is not installed by default on a debian guest here, at
least.
SLES15 either:
$ lzop
If 'lzop' is not a typo you can use command-not-found to lookup the package that contains it, like this:
cnf lzop
> Is it necessary to check this earlier?
Yes, see above.
> If you get this error, you just need to install the tool.
> Then, you can re-run the incremental build.
Actually, I'd prefer the build to fail early so that machine can
continue with the next build.
> BTW, this patch has a drawback.
>
> [1] Enable CONFIG_KERNEL_LZ4 on the system
> without lz4c installed
>
> [2] Run 'make' and you will get the error
> "lz4 tool not found on this system but CONFIG_KERNEL_LZ4 enabled"
>
> [3] Run 'make menuconfig' and
> switch from CONFIG_KERNEL_LZ4 to CONFIG_KERNEL_GZIP
>
> [4] Run 'make' and you will still get the same error
> even after you have chosen to use GZIP instead of LZ4.
Well, there's code in Makefile to refresh include/config/auto.conf but
for whatever reason that make in step 4 doesn't run it.
And *that* looks like a bug - if a user runs "make menuconfig" and
.config gets updated, then include/config/auto.conf better get updated
too. Right?
Thx.
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.
next prev parent reply other threads:[~2018-10-11 8:52 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-10-10 22:23 [PATCH] kbuild: Fail the build early when no lz4 present Borislav Petkov
2018-10-10 22:34 ` Randy Dunlap
2018-10-11 4:26 ` Masahiro Yamada
2018-10-11 8:52 ` Borislav Petkov [this message]
2018-10-11 15:08 ` Masahiro Yamada
2018-10-11 15:32 ` Borislav Petkov
2018-10-16 9:17 ` Masahiro Yamada
2018-10-11 20:33 ` kbuild test robot
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20181011085234.GA25435@zn.tnic \
--to=bp@alien8.de \
--cc=linux-kbuild@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=michal.lkml@markovi.net \
--cc=yamada.masahiro@socionext.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).