Re: [RFT] Testing 1.22

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


[Index of Archives]     [Linux Samsung SoC]     [Linux Rockchip SoC]     [Linux Actions SoC]     [Linux for Synopsys ARC Processors]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]


  Powered by Linux