Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
From:   Florian Weimer <fweimer@redhat.com>
To:     Ian Rogers <irogers@google.com>
Cc:     Arnaldo Carvalho de Melo <acme@kernel.org>,
        linux-perf-users@vger.kernel.org, linux-kernel@vger.kernel.org,
        Peter Zijlstra <peterz@infradead.org>,
        Ingo Molnar <mingo@redhat.com>,
        Mark Rutland <mark.rutland@arm.com>,
        Alexander Shishkin <alexander.shishkin@linux.intel.com>,
        Jiri Olsa <jolsa@kernel.org>,
        Namhyung Kim <namhyung@kernel.org>,
        Adrian Hunter <adrian.hunter@intel.com>,
        "Justin M. Forbes" <jforbes@fedoraproject.org>
Subject: Re: [PATCH v2] perf: Avoid implicit function declarations in
 lexer/parse interface
References: <87sfcn7uot.fsf@oldenburg.str.redhat.com>
        <CAP-5=fXZv+KCdCN05wVUcAwDCZAgXjWunoaviGBQEiUPqNwOmg@mail.gmail.com>
        <ZEx0IQAtBatrRDCR@kernel.org> <ZEx0xAamEl66qk2w@kernel.org>
        <874jot69ks.fsf@oldenburg.str.redhat.com>
        <87zg6l4utl.fsf@oldenburg.str.redhat.com>
        <ZFJ39HKzBUg64QPO@kernel.org>
        <CAP-5=fUukHuVsPS_Am6VTGvpuiEVo=2X=BuN2feh+ibhnSFAUg@mail.gmail.com>
Date:   Wed, 03 May 2023 18:45:12 +0200
In-Reply-To: <CAP-5=fUukHuVsPS_Am6VTGvpuiEVo=2X=BuN2feh+ibhnSFAUg@mail.gmail.com>
        (Ian Rogers's message of "Wed, 3 May 2023 08:28:22 -0700")
Message-ID: <87a5yl4b53.fsf@oldenburg.str.redhat.com>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.2 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

* Ian Rogers:

> On Wed, May 3, 2023 at 8:04=E2=80=AFAM Arnaldo Carvalho de Melo <acme@ker=
nel.org> wrote:
>>
>> Em Wed, May 03, 2023 at 11:40:06AM +0200, Florian Weimer escreveu:
>> > * Florian Weimer:
>> > > * Arnaldo Carvalho de Melo:
>>
>> > >>> Thanks, applied. BTW b4 coulnd't find this message (nor the origin=
al):
>>
>> > > Yes, vger drops the message after accepting it for some reason, prob=
ably
>> > > something in the patch contents.  I tried to resubmit from a complet=
ely
>> > > separate account, no luck.
>> > >
>> > >> Not so fast, removed it for now:
>> > >>
>> > >>   CC      /tmp/build/perf-tools-next/util/parse-events-bison.o
>> > >> In file included from util/pmu.y:14:
>> > >> /tmp/build/perf-tools-next/util/pmu-flex.h:496:1: error: unknown ty=
pe name =E2=80=98YYSTYPE=E2=80=99
>> > >>   496 |
>> > >>       | ^
>> > >> /tmp/build/perf-tools-next/util/pmu-flex.h:498:19: error: unknown t=
ype name =E2=80=98YYSTYPE=E2=80=99
>> > >>   498 |
>> > >>       |                   ^
>> > >> /tmp/build/perf-tools-next/util/pmu-flex.h:546:17: error: unknown t=
ype name =E2=80=98YYSTYPE=E2=80=99
>> > >>   546 | extern int yylex \
>> > >>       |                 ^~
>> > >> util/pmu-bison.c: In function =E2=80=98perf_pmu_parse=E2=80=99:
>> > >> /tmp/build/perf-tools-next/util/pmu-bison.c:69:25: error: implicit =
declaration of function =E2=80=98perf_pmu_lex=E2=80=99; did you mean =E2=80=
=98perf_pmu_free=E2=80=99? [-Werror=3Dimplicit-function-declaration]
>> > >>    69 | #define yylex           perf_pmu_lex
>> > >>       |                         ^~~~~~~~~~~~
>> > >> util/pmu-bison.c:1007:16: note: in expansion of macro =E2=80=98yyle=
x=E2=80=99
>> > >
>> > > This appears to be related to some BPF filter stuff that is only in
>> > > perf-next, not mainline.
>> > >
>> > > Is this the right tree on which to base the patch?
>> > >
>> > >   <https://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git/>
>> > >
>> > > Branch perf-tools-next?
>> >
>> > Sorry, it doesn't build even without my patch:
>> >
>> > make[4]: *** No rule to make target 'zip.h', needed by '/tmp/build/lib=
bpf/staticobjs/libbpf.o'.  Stop.
>>
>> I'm noticing this, but then I haven't merged with upstream yet, I bet
>> this is something upstream after merging the bpf branch... Nope, I just
>> did a test merge of what is in
>> git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git perf-tools
>> with upstream and it builds without problems on:
>>
>> [acme@quaco perf-tools]$ head -2 /etc/os-release
>> NAME=3D"Fedora Linux"
>> VERSION=3D"37 (Workstation Edition)"
>> [acme@quaco perf-tools]$
>>
>> I'll check on f38 and rawhide.
>>
>> - Arnaldo
>
> The zip.c and zip.h in libbpf are new, perhaps it is a fixdeps issue?
> Perhaps doing a clean build and retrying will address the problem.

Yeah, it's that.  I tried to reproduce the issue with a make command
similar to Arnaldo's, and forgot that *of course* O=3D overrides =E2=80=9Cg=
it
clean=E2=80=9D.

I'm now on 5d27a645f60940fdf589e4ff5351506a7f0fdbaa, can built it
cleanly, and will try to rebase my patch onto that.

Thanks,
Florian