[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200825165029.795a8428@canb.auug.org.au>
Date: Tue, 25 Aug 2020 16:50:29 +1000
From: Stephen Rothwell <sfr@...b.auug.org.au>
To: Alexei Starovoitov <alexei.starovoitov@...il.com>
Cc: Daniel Borkmann <daniel@...earbox.net>,
Alexei Starovoitov <ast@...nel.org>,
Networking <netdev@...r.kernel.org>,
Linux Next Mailing List <linux-next@...r.kernel.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
David Miller <davem@...emloft.net>
Subject: Re: linux-next: build failure after merge of the bpf-next tree
Hi Alexei,
On Mon, 24 Aug 2020 20:27:28 -0700 Alexei Starovoitov <alexei.starovoitov@...il.com> wrote:
>
> I didn't receive the first email you've replied to.
> The build error is:
> "
> No libelf found
> make[5]: *** [Makefile:284: elfdep] Error 1
> "
> and build process stops because libelf is not found, right?
> That is expected and necessary.
> bpf_preload needs libbpf that depends on libelf.
> The only 'fix' is to turn off bpf_preload.
> It's off by default.
> allmodconfig cannot build bpf_preload umd if there is no libelf.
> There is CC_CAN_LINK that does feature detection.
> We can extend scripts/cc-can-link.sh or add another script that
> will do CC_CAN_LINK_LIBELF, but such approach doesn't scale.
> imo it's cleaner to rely on feature detection by libbpf Makefile with
> an error above instead of adding such knobs to top Kconfig.
> Does it make sense?
Sorry, but if this is not necessary to build the kernel, then an
allmodconfig build needs to succeed so you need to do the detection and
turn it off automatically. Or you could make it so that it has to be
manually enabled in all circumstances.
--
Cheers,
Stephen Rothwell
Content of type "application/pgp-signature" skipped
Powered by blists - more mailing lists