Re: [RFT] Testing 1.22

From: "Michal Suchánek" <msuchanek@suse.de>
To: Luca Boccassi <bluca@debian.org>
Cc: Arnaldo Carvalho de Melo <acme@kernel.org>,
	Andrii Nakryiko <andrii@kernel.org>, Jiri Olsa <jolsa@kernel.org>,
	dwarves@vger.kernel.org, bpf@vger.kernel.org, kernel-team@fb.com,
	Michael Petlan <mpetlan@redhat.com>
Subject: Re: [RFT] Testing 1.22
Date: Sat, 17 Jul 2021 18:36:26 +0200	[thread overview]
Message-ID: <20210717163626.GN24916@kitsune.suse.cz> (raw)
In-Reply-To: <b07015ebd7bbadb06a95a5105d9f6b4ed5817b2f.camel@debian.org>

On Sat, Jul 17, 2021 at 04:14:54PM +0100, Luca Boccassi wrote:
> On Sat, 2021-07-17 at 17:10 +0200, Michal Suchánek wrote:
> > Hello,
...
> > 
> > So this libbpf comes from the kernel, and there is a separate github
> > repository for libbpf.
> > 
> > Should the kernel ship its own copy of the library?
> > 
> > Seeing that the one in the kernel is 0.3.0 and the required one for
> > dwarves is 0.4.0 maybe the one in the kernel needs updating if it needs
> > to be shipped there?
> > 
> > I wil file a bug to build the libbpf from the git repo instead of the
> > kernel to make the openSUSE libbpf less baroque.
> 
> They provide the same ABI, so there should be only one in the same
> distro, the kernel package shouldn't ship its own copy if there's a
> standalone package built from the standalone sources.
> If you are asking why the sources are still present in the upstream
> kernel, I don't know - maybe historical reasons, since that's where it
> came from? But AFAIK the majority of distros don't use that anymore.

FWIW the libbpf from github does not work for me with LTO (GCC 11).

Also there is a problem that LIBDIR is /usr/lib64 on arm64 ppc64(le) and
s390x but the library gets installed into /usr/lib by default. For some
reason x86_64 is the only 64bit arch that works out of the box.

Thanks

Michal