Re: [PATCH v3 1/2] perf build: Properly guard libbpf includes

From: Jiri Olsa <olsajiri@gmail.com>
To: Arnaldo Carvalho de Melo <acme@kernel.org>
Cc: Ian Rogers <irogers@google.com>,
	Mike Leach <mike.leach@linaro.org>,
	linux-perf-users@vger.kernel.org, linux-kernel@vger.kernel.org,
	bpf@vger.kernel.org, peterz@infradead.org, mingo@redhat.com,
	mark.rutland@arm.com, alexander.shishkin@linux.intel.com,
	namhyung@kernel.org
Subject: Re: [PATCH v3 1/2] perf build: Properly guard libbpf includes
Date: Mon, 9 Jan 2023 19:10:18 +0100	[thread overview]
Message-ID: <Y7xYimp0h4YT72/N@krava> (raw)
In-Reply-To: <Y7wuz6EOggZ8Wysb@kernel.org>

On Mon, Jan 09, 2023 at 12:12:15PM -0300, Arnaldo Carvalho de Melo wrote:
> Em Fri, Jan 06, 2023 at 11:06:46AM -0800, Ian Rogers escreveu:
> > So trying to get build-test working on my Debian derived distro is a
> > PITA with broken feature detection for options I don't normally use.
> 
> Its really difficult to have perf building with so many dependent
> libraries, mowing out some should be in order.
> 
> > I'll try to fix this.
> 
> Thanks.
>  
> > In any case I think I've spotted what is really happening here and it
> > isn't a failure but a feature :-D The build is specifying
> 
> I get it.
> 
> > LIBBPF_DYNAMIC=1 which means you get the libbpf headers from
> > /usr/include. I think the build is trying to do this on a system with
> > an old libbpf and hence getting the failures above. Previously, even
> > though we wanted the dynamic headers we still had a -I, this time for
> > the install_headers version. Now you really are using the system
> > version and it is broken. This means a few things:
> > - the libbpf feature test should fail if code like above is going to fail,
> 
> Agreed.
> 
> > - we may want to contemplate supporting older libbpfs (I'd rather not),
> 
> I'd rather require everybody to be up to the latest trends, but I really
> don't think that is a reasonable expectation.
> 
> > - does build-test have a way to skip known issues like this?
> 
> Unsure, Jiri?

I don't think so it just triggers the build, it's up to the features check
to disable the feature if the library is not compatible with perf code

could we add that specific libbpf call to the libbpf feature check?

jirka

> 
> But yeah, previous experiences with Andrii were that we can do not too
> costly feature checks, not using .c programs that would fail if some
> required feature wasn't present but instead would just do some grep on a
> header and if some "smell" wasn't scent, just fail the cap query.
> 
> - Arnaldo