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
