Public bug reported:

The perf tool has an optional dependency on libbfd. Per Debian policy,
and due to some situation involving parallel installations of this
library, no packages should link dynamically against libbfd. In the
past, bugs have been filed to link perf statically against libbfd in bug
783660 (from 2011) and then to just not link against it at all in bug
1748922 (from 2018) and bug 1828234 (from 2019). The argument was made
that perf does not need this dependency, as perf can use libiberty as an
alternative to demangle C++ names.

However, that is not the only thing perf is using libbfd for: the other
is to implement an inlined version of addr2line. This was part of an
important patchset from 2013 that strove to improve the performance of
perf. In my case, I ran my program for all of 30 seconds, generating a
163M large trace, and have been waiting almost an hour for the events to
process... and it is only a third of the way done; what I see it doing
is spawning, over and over and over again, addr2line, which it wouldn't
do if linked against libbfd.

https://lore.kernel.org/patchwork/patch/413455/

Is it possible to link perf statically against libbfd, in order to let
it use the in-process implementation of addr2line? That is the solution
that I've understood for other packages, such as oprofile in bug 426614
and bug 588033. Doing a quick grep of the code of perf for
HAVE_LIBBFD_SUPPORT, it seems like bpf disassembly support is also
dependent on libbfd (and so while it is great that Ubuntu's build of
perf has been compiled against libbpf, it seems like that functionality
is being hampered by the lack of linking libbfd).

** Affects: linux (Ubuntu)
     Importance: Undecided
         Status: New

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1894407

Title:
  linux-tools: can perf be linked against libbfd, maybe statically?

Status in linux package in Ubuntu:
  New

Bug description:
  The perf tool has an optional dependency on libbfd. Per Debian policy,
  and due to some situation involving parallel installations of this
  library, no packages should link dynamically against libbfd. In the
  past, bugs have been filed to link perf statically against libbfd in
  bug 783660 (from 2011) and then to just not link against it at all in
  bug 1748922 (from 2018) and bug 1828234 (from 2019). The argument was
  made that perf does not need this dependency, as perf can use
  libiberty as an alternative to demangle C++ names.

  However, that is not the only thing perf is using libbfd for: the
  other is to implement an inlined version of addr2line. This was part
  of an important patchset from 2013 that strove to improve the
  performance of perf. In my case, I ran my program for all of 30
  seconds, generating a 163M large trace, and have been waiting almost
  an hour for the events to process... and it is only a third of the way
  done; what I see it doing is spawning, over and over and over again,
  addr2line, which it wouldn't do if linked against libbfd.

  https://lore.kernel.org/patchwork/patch/413455/

  Is it possible to link perf statically against libbfd, in order to let
  it use the in-process implementation of addr2line? That is the
  solution that I've understood for other packages, such as oprofile in
  bug 426614 and bug 588033. Doing a quick grep of the code of perf for
  HAVE_LIBBFD_SUPPORT, it seems like bpf disassembly support is also
  dependent on libbfd (and so while it is great that Ubuntu's build of
  perf has been compiled against libbpf, it seems like that
  functionality is being hampered by the lack of linking libbfd).

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1894407/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to     : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp

Reply via email to