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 16:19 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.