All of lore.kernel.org
 help / color / mirror / Atom feed
From: Luca Boccassi <bluca@debian.org>
To: "Michal Suchánek" <msuchanek@suse.de>
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 15:35:03 +0100	[thread overview]
Message-ID: <f699a04791efbb6936ef19a8dbfc99f6e77e7136.camel@debian.org> (raw)
In-Reply-To: <20210716201248.GL24916@kitsune.suse.cz>

[-- Attachment #1: Type: text/plain, Size: 7003 bytes --]

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
$ rpm -qlp /tmp/libbpf-devel-5.12.4-2.7.x86_64.rpm 
warning: /tmp/libbpf-devel-5.12.4-2.7.x86_64.rpm: Header V3 RSA/SHA256
Signature, key ID 3dbdc284: NOKEY
/usr/include/bpf
/usr/include/bpf/bpf.h
/usr/include/bpf/bpf_core_read.h
/usr/include/bpf/bpf_endian.h
/usr/include/bpf/bpf_helper_defs.h
/usr/include/bpf/bpf_helpers.h
/usr/include/bpf/bpf_tracing.h
/usr/include/bpf/btf.h
/usr/include/bpf/libbpf.h
/usr/include/bpf/libbpf_common.h
/usr/include/bpf/libbpf_util.h
/usr/include/bpf/xsk.h
/usr/lib64/libbpf.so
/usr/lib64/pkgconfig/libbpf.pc

After hacking it out in the libbpf build:

https://build.opensuse.org/package/show/home:bluca:branches:home:michals/libbpf

Dwarves then builds just fine with system libbpf:

https://build.opensuse.org/package/show/home:bluca:branches:home:michals/dwarves

Here's a PR for the libbpf package that applies a quick hack to fix it:

https://build.opensuse.org/request/show/906834

I'll send my invoice to SUSE Inc. ;-)

-- 
Kind regards,
Luca Boccassi

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

  parent reply	other threads:[~2021-07-17 14:35 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-27 15:20 [RFT] Testing 1.22 Arnaldo Carvalho de Melo
2021-05-27 16:54 ` Andrii Nakryiko
2021-05-27 19:04   ` Arnaldo
2021-05-27 19:14     ` Andrii Nakryiko
2021-05-27 19:55       ` Arnaldo
2021-05-27 20:41         ` Andrii Nakryiko
2021-05-27 21:08           ` Jiri Olsa
2021-05-27 21:57             ` Arnaldo
2021-05-28 19:45           ` Arnaldo Carvalho de Melo
2021-05-29  2:36             ` Andrii Nakryiko
2021-06-01 18:31               ` Arnaldo Carvalho de Melo
2021-06-01 18:32                 ` Arnaldo Carvalho de Melo
2021-05-30  0:40             ` Andrii Nakryiko
2021-06-01 18:24               ` Arnaldo Carvalho de Melo
2021-06-03 14:57               ` Arnaldo Carvalho de Melo
2021-06-05  2:55                 ` Andrii Nakryiko
2021-06-07 13:20                   ` Parallelizing vmlinux BTF encoding. was " Arnaldo Carvalho de Melo
2021-06-07 15:42                     ` Yonghong Song
2021-06-08  0:53                     ` Andrii Nakryiko
2021-06-08 12:59                       ` Arnaldo Carvalho de Melo
2021-06-15 19:01                         ` Arnaldo Carvalho de Melo
2021-06-15 19:13                           ` Andrii Nakryiko
2021-06-15 19:38                             ` Arnaldo Carvalho de Melo
2021-06-15 20:05                               ` Andrii Nakryiko
2021-06-15 20:25                                 ` Arnaldo Carvalho de Melo
2021-06-15 21:26                                   ` Andrii Nakryiko
2021-05-30 21:45             ` Jiri Olsa
2021-06-01 19:07               ` Arnaldo Carvalho de Melo
2021-06-02 10:21 ` Michael Petlan
2021-07-15 21:31 ` Michal Suchánek
2021-07-16 13:25   ` Arnaldo Carvalho de Melo
2021-07-16 13:35     ` Luca Boccassi
2021-07-16 19:08       ` Luca Boccassi
     [not found]         ` <20210716201248.GL24916@kitsune.suse.cz>
2021-07-17 14:35           ` Luca Boccassi [this message]
2021-07-17 15:10             ` Michal Suchánek
2021-07-17 15:14               ` Luca Boccassi
2021-07-17 16:36                 ` Michal Suchánek
2021-07-17 16:39                   ` Luca Boccassi
2021-07-19 10:30                 ` Michal Suchánek
2021-07-19 10:34                   ` Luca Boccassi
2021-07-19 12:10     ` Luca Boccassi
2021-07-19 21:08       ` Arnaldo Carvalho de Melo
2021-07-28 10:53         ` Expected release date of v1.22 Deepak Kumar Mishra
2021-07-28 11:21           ` Greg KH

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=f699a04791efbb6936ef19a8dbfc99f6e77e7136.camel@debian.org \
    --to=bluca@debian.org \
    --cc=acme@kernel.org \
    --cc=andrii@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=dwarves@vger.kernel.org \
    --cc=jolsa@kernel.org \
    --cc=kernel-team@fb.com \
    --cc=mpetlan@redhat.com \
    --cc=msuchanek@suse.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.