From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752505AbdBNIAj (ORCPT ); Tue, 14 Feb 2017 03:00:39 -0500 Received: from relay6-d.mail.gandi.net ([217.70.183.198]:57271 "EHLO relay6-d.mail.gandi.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751490AbdBNIAL (ORCPT ); Tue, 14 Feb 2017 03:00:11 -0500 X-Originating-IP: 209.85.220.178 MIME-Version: 1.0 In-Reply-To: <58A241EC.8050400@fb.com> References: <20170214091250.57d054b2@canb.auug.org.au> <58A241EC.8050400@fb.com> From: Joe Stringer Date: Mon, 13 Feb 2017 23:59:42 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: linux-next: build failure after merge of the net tree To: Alexei Starovoitov Cc: Stephen Rothwell , David Miller , Networking , linux-next@vger.kernel.org, LKML , Peter Zijlstra , Ingo Molnar , Arnaldo Carvalho de Melo , Alexander Shishkin , Daniel Borkmann , Jesper Dangaard Brouer , Wang Nan Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 13 February 2017 at 15:31, Alexei Starovoitov wrote: > On 2/13/17 2:12 PM, Stephen Rothwell wrote: >> >> Hi all, >> >> After merging the net tree, today's linux-next build (powerpc64le perf) >> failed like this: >> >> Warning: tools/include/uapi/linux/bpf.h differs from kernel >> bpf.c: In function 'bpf_prog_attach': >> bpf.c:180:6: error: 'union bpf_attr' has no member named 'attach_flags'; >> did you mean 'map_flags'? >> attr.attach_flags = flags; >> ^ >> >> Caused by commit >> >> 7f677633379b ("bpf: introduce BPF_F_ALLOW_OVERRIDE flag") >> >> Unfortunately, the perf header files are kept separate from the kernel >> header files proper and are not automatically copied over :-( >> >> I have applied the following build fix patch for today. > > > Yes. Thanks for the fix. It's more than a merge conflict. > I should have added it in the first place. Now we have both > perf and samples/bpf depend on tools/lib/bpf and I simply > forgot about this dependency, since building perf > is not my typical workflow. > > Joe, > can you think of a way to make tools/lib/bpf to > use tools/include only? > Right now we just pull tools/lib/bpf/bpf.o in samples/bpf/Makefile > and that's a hack that caused this issue. > samples/bpf/ needs to depend on libbpf.a properly. Honestly the build system stuff is all black magic to me. Originally I had a line in the samples/bpf makefile that changed directory and ran make there, but it was limited in that it only addressed the 'all' target so you could still hit issues when trying to build specific samples directly via their own targets so I removed it on request: https://patchwork.kernel.org/patch/9472573/