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, > > > > On Sat, Jul 17, 2021 at 03:35:03PM +0100, Luca Boccassi wrote: > > > On Fri, 2021-07-16 at 22:12 +0200, Michal Suchánek wrote: > > > > On Fri, Jul 16, 2021 at 08:08:27PM +0100, Luca Boccassi wrote: > > > > > On Fri, 2021-07-16 at 14:35 +0100, Luca Boccassi wrote: > > > > > > On Fri, 2021-07-16 at 10:25 -0300, Arnaldo Carvalho de Melo wrote: > > > > > > > Em Thu, Jul 15, 2021 at 11:31:20PM +0200, Michal Suchánek escreveu: > > > > > > > > Hello, > > > > > > > > > > > > > > > > when building with system libbpf I get: > > > > > > > > > > > > > > > > [ 40s] make[1]: Nothing to be done for 'preinstall'. > > > > > > > > [ 40s] make[1]: Leaving directory '/home/abuild/rpmbuild/BUILD/dwarves-1.21+git175.1ef87b2/build' > > > > > > > > [ 40s] Install the project... > > > > > > > > [ 40s] /usr/bin/cmake -P cmake_install.cmake > > > > > > > > [ 40s] -- Install configuration: "RelWithDebInfo" > > > > > > > > [ 40s] -- Installing: /home/abuild/rpmbuild/BUILDROOT/dwarves-1.21+git175.1ef87b2-15.1.ppc64le/usr/bin/codiff > > > > > > > > [ 40s] CMake Error at cmake_install.cmake:63 (file): > > > > > > > > [ 40s] file RPATH_CHANGE could not write new RPATH: > > > > > > > > [ 40s] > > > > > > > > [ 40s] > > > > > > > > [ 40s] > > > > > > > > [ 40s] to the file: > > > > > > > > [ 40s] > > > > > > > > [ 40s] /home/abuild/rpmbuild/BUILDROOT/dwarves-1.21+git175.1ef87b2-15.1.ppc64le/usr/bin/codiff > > > > > > > > [ 40s] > > > > > > > > [ 40s] The current RUNPATH is: > > > > > > > > [ 40s] > > > > > > > > [ 40s] /home/abuild/rpmbuild/BUILD/dwarves-1.21+git175.1ef87b2/build: > > > > > > > > [ 40s] > > > > > > > > [ 40s] which does not contain: > > > > > > > > [ 40s] > > > > > > > > [ 40s] /usr/local/lib64:/home/abuild/rpmbuild/BUILD/dwarves-1.21+git175.1ef87b2/build: > > > > > > > > [ 40s] > > > > > > > > [ 40s] as was expected. > > > > > > > > [ 40s] > > > > > > > > [ 40s] > > > > > > > > [ 40s] make: *** [Makefile:74: install] Error 1 > > > > > > > > [ 40s] make: Leaving directory '/home/abuild/rpmbuild/BUILD/dwarves-1.21+git175.1ef87b2/build' > > > > > > > > [ 40s] error: Bad exit status from /var/tmp/rpm-tmp.OaGNX4 (%install) > > > > > > > > > > > > > > > > This is not a problem with embedded libbpf. > > > > > > > > > > > > > > > > Using system libbpf seems to be new in 1.22 > > > > > > > > > > > > > > Lucca, can you take a look at this? > > > > > > > > > > > > > > Thanks, > > > > > > > > > > > > > > - Arnaldo > > > > > > > > > > > > Hi, > > > > > > > > > > > > Michal, what is the CMake configuration command line you are using? > > > > > > > > > > Latest tmp.master builds fine here with libbpf 0.4.0. To reproduce it > > > > > would be good to know build env and command line used, otherwise I > > > > > can't really tell. > > > > > > > > Indeed, there is non-trivial rpm macro expanded when invoking cmake. > > > > > > > > Attaching log. > > > > > > > > Thanks > > > > > > > > Michal > > > > > > So, this took some spelunking. TL;DR: openSUSE's libbpf.pc from libbpf- > > > devel is broken, it lists -L/usr/local/lib64 in Libs even though it > > > doesn't install anything in that prefix. Fix it to list the right path > > > and the problem goes away. > > > > > > Longer version: CMake is complaining that the rpath in the binary is > > > not what it expected it to be when stripping it. Of course the first > > > question is, why does that matter since it's removing it? Just remove > > > it, no? Another CMake weirdness to add the the list, I guess. > > > > > > [ 20s] file RPATH_CHANGE could not write new RPATH: > > > [ 20s] > > > [ 20s] > > > [ 20s] > > > [ 20s] to the file: > > > [ 20s] > > > [ 20s] /home/abuild/rpmbuild/BUILDROOT/dwarves- > > > 1.21+git175.1ef87b2-21.1.x86_64/usr/bin/codiff > > > [ 20s] > > > [ 20s] The current RUNPATH is: > > > [ 20s] > > > [ 20s] /home/abuild/rpmbuild/BUILD/dwarves- > > > 1.21+git175.1ef87b2/build: > > > [ 20s] > > > [ 20s] which does not contain: > > > [ 20s] > > > [ 20s] /usr/local/lib64:/home/abuild/rpmbuild/BUILD/dwarves- > > > 1.21+git175.1ef87b2/build: > > > [ 20s] > > > [ 20s] as was expected. > > > > > > This is the linking step where the rpath is set: > > > > > > [ 19s] /usr/bin/cc -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector- > > > strong -funwind-tables -fasynchronous-unwind-tables -fstack-clash- > > > protection -Werror=return-type -flto=auto -g -DNDEBUG > > > -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -O2 -g -DNDEBUG -flto=auto > > > -Wl,--as-needed -Wl,--no-undefined -Wl,-z,now -rdynamic > > > CMakeFiles/codiff.dir/codiff.c.o -o codiff -L/usr/local/lib64 -Wl,- > > > rpath,/usr/local/lib64:/home/abuild/rpmbuild/BUILD/dwarves- > > > 1.21+git175.1ef87b2/build: libdwarves.so.1.0.0 -ldw -lelf -lz -lbpf > > > > > > On a build without -DLIBBPF_EMBEDDED=off, this is the linking step for > > > the same binary: > > > > > > [ 64s] /usr/bin/cc -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector- > > > strong -funwind-tables -fasynchronous-unwind-tables -fstack-clash- > > > protection -Werror=return-type -flto=auto -g -DNDEBUG > > > -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -O2 -g -DNDEBUG -flto=auto > > > -Wl,--as-needed -Wl,--no-undefined -Wl,-z,now -rdynamic > > > CMakeFiles/codiff.dir/codiff.c.o -o codiff -Wl,- > > > rpath,/home/abuild/rpmbuild/BUILD/dwarves-1.21+git175.1ef87b2/build: > > > libdwarves.so.1.0.0 -ldw -lelf -lz > > > > > > /usr/local/lib64 is not in the rpath. Why? The hint is that > > > -L/usr/local/lib64 is not passed either, too much of a coincidence to > > > be unrelated. > > > > > > Where is it coming from? Well, when using the system's libbpf we are > > > using the pkgconfig file from the package. It is common to list linker > > > flags in there, although this one shouldn't be in it. Sure enough, > > > downloading libbpf-devel from > > > https://build.opensuse.org/package/binaries/openSUSE:Factory/libbpf/standard > > > and extracting the pc file: > > > > > > $ cat /tmp/libbpf.pc > > > # SPDX-License-Identifier: (LGPL-2.1 OR BSD-2-Clause) > > > > > > prefix=/usr/local > > > libdir=/usr/local/lib64 > > > includedir=${prefix}/include > > > > > > Name: libbpf > > > Description: BPF library > > > Version: 0.3.0 > > > Libs: -L${libdir} -lbpf > > > Requires.private: libelf zlib > > > Cflags: -I${includedir} > > > > > > There it is. Nothing is installed in that path, so it shouldn't be > > > there in the first place. > > > > > > $ rpm -qlp /tmp/libbpf0-5.12.4-2.7.x86_64.rpm > > > warning: /tmp/libbpf0-5.12.4-2.7.x86_64.rpm: Header V3 RSA/SHA256 > > > Signature, key ID 3dbdc284: NOKEY > > > /usr/lib64/libbpf.so.0 > > > /usr/lib64/libbpf.so.0.3.0 > > > > Thanks for the investigation > > > > 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. > > > > Thanks > > > > Michal > > 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. Apparently the libbpf github repository is only mirror of the kernel libbpf source with some modifications to build it as standalone. Thanks Michal
