dwarves.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Luca Boccassi <bluca@debian.org>
To: Dominique Martinet <asmadeus@codewreck.org>, dwarves@vger.kernel.org
Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
Subject: Re: [PATCH dwarves v3] libbpf: allow to use packaged version
Date: Tue, 30 Mar 2021 12:06:09 +0100	[thread overview]
Message-ID: <1ba2e8cdb496248b02fa31ddcccb06c1e4ca3cca.camel@debian.org> (raw)
In-Reply-To: <8cefd2c1cf59c1618365a738677afcb2ab6acd01.camel@debian.org>

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

On Tue, 2021-03-30 at 11:50 +0100, Luca Boccassi wrote:
> On Tue, 2021-03-30 at 13:47 +0900, Dominique Martinet wrote:
> > Hi,
> > 
> > I see this commit has been reverted just before the 1.20 release in Feb:
> > ---
> > Revert "libbpf: allow to use packaged version"
> > 
> > This reverts commit 82749180b23d3c9c060108bc290ae26507fc324e.
> > 
> > Getting in the way of releasing 1.20, breaking the build of a dwarves
> > rpm when a libbpf package is installed in a fedora 33 system:
> > 
> > In file included from /home/acme/rpmbuild/BUILD/dwarves-1.20/strings.c:7:
> > /home/acme/rpmbuild/BUILD/dwarves-1.20/pahole_strings.h:9:10: fatal error: bpf/btf.h: No such file or directory
> >     9 | #include <bpf/btf.h>
> >       |          ^~~~~~~~~~~
> > 
> > Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
> > ---
> > 
> > I can understand reverting due to other pressure to get a release out
> > but most distros (including fedora) frown upon vendoring code so I think
> > it would be good to have back ultimately.
> > 
> > Did you or someone else (Luca?) ever take the time to look at it?
> > 
> > I don't see what would be so different with fedora to make this
> > unfixable, I'd be happy taking a look if nobody has so far.
> > Would you take the patch back in if I somehow fix rpmbuild with a libbpf
> > package installed on fedora33?
> > 
> > 
> > Thanks,
> 
> Hi,
> 
> I did not realise it was reverted (if I was pinged and I missed it:
> sorry about that) - what was the issue precisely? This has been used on
> Ubuntu and Debian for a few months now, no problems reported.
> Happy to have a look too if needed.

As far as I can see, on Fedora 33 the only CMake option used is '-
DCMAKE_BUILD_TYPE=Release':

https://src.fedoraproject.org/rpms/dwarves/blob/f33/f/dwarves.spec

On my Debian system, with libbpf-dev installed and after re-instating
the patch on an up-to-date master branch of pahole.git, this builds
just fine:

$ git clone https://git.kernel.org/pub/scm/devel/pahole/pahole.git
Cloning into 'pahole'...
remote: Enumerating objects: 6367, done.
remote: Total 6367 (delta 0), reused 0 (delta 0), pack-reused 6367
Receiving objects: 100% (6367/6367), 1.59 MiB | 11.49 MiB/s, done.
Resolving deltas: 100% (4450/4450), done.
$ cd pahole/
$ git revert 7943374
Auto-merging pahole.c
Auto-merging libbtf.h
Auto-merging libbtf.c
Auto-merging btf_loader.c
Auto-merging btf_encoder.c
Auto-merging CMakeLists.txt
[master 44b9227] Revert "Revert "libbpf: allow to use packaged version""
 9 files changed, 41 insertions(+), 24 deletions(-)
 create mode 120000 lib/include/bpf
$ mkdir b
$ cd b
$ cmake .. -DCMAKE_BUILD_TYPE=Release
-- The C compiler identification is GNU 8.3.0
-- Check for working C compiler: /usr/bin/ccache
-- Check for working C compiler: /usr/bin/ccache -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Checking availability of DWARF and ELF development libraries
-- Looking for dwfl_module_build_id in elf
-- Looking for dwfl_module_build_id in elf - found
-- Found dwarf.h header: /usr/include
-- Found elfutils/libdw.h header: /usr/include
-- Found libdw library: /usr/lib/x86_64-linux-gnu/libdw.so
-- Found libelf library: /usr/lib/x86_64-linux-gnu/libelf.so
-- Checking availability of DWARF and ELF development libraries - done
-- Found ZLIB: /usr/lib/x86_64-linux-gnu/libz.so (found version "1.2.11") 
-- Submodule update
Submodule 'lib/bpf' (https://github.com/libbpf/libbpf) registered for path 'lib/bpf'
Cloning into '/home/bluca/git/pahole/lib/bpf'...
Submodule path 'lib/bpf': checked out '986962fade5dfa89c2890f3854eb040d2a64ab38'
-- Submodule update - done
-- Performing Test HAVE_REALLOCARRAY_SUPPORT
-- Performing Test HAVE_REALLOCARRAY_SUPPORT - Success
-- Configuring done
-- Generating done
-- Build files have been written to: /home/bluca/git/pahole/b
$ make -j5
Scanning dependencies of target bpf
[  1%] Building C object CMakeFiles/bpf.dir/lib/bpf/src/bpf.c.o
[  5%] Building C object CMakeFiles/bpf.dir/lib/bpf/src/btf.c.o
[  5%] Building C object CMakeFiles/bpf.dir/lib/bpf/src/hashmap.c.o
[  7%] Building C object CMakeFiles/bpf.dir/lib/bpf/src/bpf_prog_linfo.c.o
[  9%] Building C object CMakeFiles/bpf.dir/lib/bpf/src/btf_dump.c.o
[ 11%] Building C object CMakeFiles/bpf.dir/lib/bpf/src/libbpf.c.o
[ 13%] Building C object CMakeFiles/bpf.dir/lib/bpf/src/libbpf_probes.c.o
[ 15%] Building C object CMakeFiles/bpf.dir/lib/bpf/src/libbpf_errno.c.o
[ 16%] Building C object CMakeFiles/bpf.dir/lib/bpf/src/nlattr.c.o
[ 18%] Building C object CMakeFiles/bpf.dir/lib/bpf/src/netlink.c.o
[ 20%] Building C object CMakeFiles/bpf.dir/lib/bpf/src/str_error.c.o
[ 22%] Building C object CMakeFiles/bpf.dir/lib/bpf/src/ringbuf.c.o
[ 24%] Building C object CMakeFiles/bpf.dir/lib/bpf/src/xsk.c.o
[ 24%] Built target bpf
Scanning dependencies of target dwarves
[ 28%] Building C object CMakeFiles/dwarves.dir/dwarves.c.o
[ 28%] Building C object CMakeFiles/dwarves.dir/strings.c.o
[ 30%] Building C object CMakeFiles/dwarves.dir/gobuffer.c.o
[ 32%] Building C object CMakeFiles/dwarves.dir/dwarves_fprintf.c.o
[ 33%] Building C object CMakeFiles/dwarves.dir/ctf_encoder.c.o
[ 35%] Building C object CMakeFiles/dwarves.dir/libctf.c.o
[ 37%] Building C object CMakeFiles/dwarves.dir/btf_encoder.c.o
[ 39%] Building C object CMakeFiles/dwarves.dir/btf_loader.c.o
[ 41%] Building C object CMakeFiles/dwarves.dir/ctf_loader.c.o
[ 43%] Building C object CMakeFiles/dwarves.dir/libbtf.c.o
[ 47%] Building C object CMakeFiles/dwarves.dir/dwarf_loader.c.o
[ 47%] Building C object CMakeFiles/dwarves.dir/dutil.c.o
[ 49%] Building C object CMakeFiles/dwarves.dir/elf_symtab.c.o
[ 50%] Building C object CMakeFiles/dwarves.dir/rbtree.c.o
[ 52%] Linking C shared library libdwarves.so
[ 52%] Built target dwarves
Scanning dependencies of target pglobal
Scanning dependencies of target dwarves_emit
Scanning dependencies of target codiff
Scanning dependencies of target dwarves_reorganize
Scanning dependencies of target dtagnames
[ 54%] Building C object CMakeFiles/pglobal.dir/pglobal.c.o
[ 56%] Building C object CMakeFiles/dwarves_emit.dir/dwarves_emit.c.o
[ 58%] Building C object CMakeFiles/codiff.dir/codiff.c.o
[ 60%] Building C object CMakeFiles/dwarves_reorganize.dir/dwarves_reorganize.c.o
[ 62%] Building C object CMakeFiles/dtagnames.dir/dtagnames.c.o
[ 64%] Linking C executable pglobal
[ 66%] Linking C shared library libdwarves_emit.so
[ 67%] Linking C executable codiff
[ 69%] Linking C shared library libdwarves_reorganize.so
[ 71%] Linking C executable dtagnames
[ 71%] Built target pglobal
[ 71%] Built target codiff
[ 71%] Built target dtagnames
Scanning dependencies of target prefcnt
[ 71%] Built target dwarves_emit
Scanning dependencies of target scncopy
Scanning dependencies of target syscse
[ 71%] Built target dwarves_reorganize
[ 73%] Building C object CMakeFiles/prefcnt.dir/prefcnt.c.o
Scanning dependencies of target pdwtags
[ 75%] Building C object CMakeFiles/scncopy.dir/scncopy.c.o
[ 77%] Building C object CMakeFiles/syscse.dir/syscse.c.o
[ 79%] Building C object CMakeFiles/scncopy.dir/elfcreator.c.o
[ 81%] Linking C executable prefcnt
[ 83%] Building C object CMakeFiles/pdwtags.dir/pdwtags.c.o
Scanning dependencies of target ctracer
[ 86%] Linking C executable scncopy
[ 86%] Linking C executable syscse
[ 88%] Linking C executable pdwtags
[ 90%] Building C object CMakeFiles/ctracer.dir/ctracer.c.o
[ 92%] Linking C executable ctracer
[ 92%] Built target prefcnt
[ 92%] Built target syscse
[ 92%] Built target scncopy
Scanning dependencies of target pfunct
Scanning dependencies of target pahole
[ 92%] Built target pdwtags
[ 94%] Building C object CMakeFiles/pfunct.dir/pfunct.c.o
[ 96%] Building C object CMakeFiles/pahole.dir/pahole.c.o
[ 96%] Built target ctracer
[ 98%] Linking C executable pfunct
[100%] Linking C executable pahole
[100%] Built target pahole
[100%] Built target pfunct

Is there anything else/some other steps that I am missing?

-- 
Kind regards,
Luca Boccassi

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

  reply	other threads:[~2021-03-30 11:06 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-02 18:22 [PATCH dwarves] libbpf: allow to use packaged version Luca Boccassi
2021-01-03 19:10 ` Andrii Nakryiko
2021-01-03 21:30   ` Luca Boccassi
2021-01-04 20:23     ` Andrii Nakryiko
2021-01-04 22:17       ` Luca Boccassi
2021-01-21 13:29         ` Arnaldo Carvalho de Melo
2021-01-21 20:02           ` Andrii Nakryiko
2021-01-21 20:33             ` Arnaldo Carvalho de Melo
2021-01-21 20:34             ` Arnaldo Carvalho de Melo
2021-01-21 21:19               ` Luca Boccassi
2021-01-15 15:29       ` Arnaldo Carvalho de Melo
2021-01-15 15:40         ` Luca Boccassi
2021-06-09 16:07           ` Arnaldo Carvalho de Melo
2021-06-09 16:11             ` Luca Boccassi
2021-01-03 21:32 ` [PATCH dwarves v2] " Luca Boccassi
2021-01-04 22:16   ` [PATCH dwarves v3] " Luca Boccassi
2021-01-13 11:18     ` Arnaldo Carvalho de Melo
2021-03-30  4:47     ` Dominique Martinet
2021-03-30 10:50       ` Luca Boccassi
2021-03-30 11:06         ` Luca Boccassi [this message]
2021-03-30 11:45           ` Dominique Martinet
2021-03-30 15:12       ` Arnaldo Carvalho de Melo
2021-03-31  1:05         ` Dominique Martinet
2021-04-13 13:42           ` Luca Boccassi
2021-05-18 14:07             ` Luca Boccassi
2021-06-09  4:10               ` Dominique Martinet
2021-06-09 16:25     ` Arnaldo Carvalho de Melo
2021-06-09 16:38       ` Arnaldo Carvalho de Melo
2021-06-09 16:43         ` Luca Boccassi

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=1ba2e8cdb496248b02fa31ddcccb06c1e4ca3cca.camel@debian.org \
    --to=bluca@debian.org \
    --cc=acme@redhat.com \
    --cc=asmadeus@codewreck.org \
    --cc=dwarves@vger.kernel.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).