On Sat, 2021-07-17 at 18:36 +0200, Michal Suchánek wrote: > 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 I don't know about LTO - but for LIBDIR, you can use LIBSUBDIR= like we do in Debian: https://tracker.debian.org/media/packages/libb/libbpf/rules-0.4.0-1 -- Kind regards, Luca Boccassi
Attachment:
signature.asc
Description: This is a digitally signed message part
