On Mon, 2021-07-19 at 12:30 +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, > > > > > > 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 Yes the source code is mirrored, IIRC the main difference is in the makefiles which are more standalone-build-friendly than the kernel's. -- Kind regards, Luca Boccassi
Attachment:
signature.asc
Description: This is a digitally signed message part
