Re: Bug#950414: binutils-dev: failed to build linux perf (tools/perf) due to missing functions

* Matthias Klose | 2020-02-03 22:29:21 [+0100]:

[CCing Alan Modra, H.J. Lu, Nick Clifton & Arnaldo]

Ok, I tried to check what happens:

- Alan Modra modified the bfd_section_* macros (see commit fd3619828e94a)
  upstream (https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=summary)
  Or in other words: this patch removed/renamed the macros silently. This was
  back in September last Year. No __attribute__ deprecation warning or other
  information was given a priori to react.
- This went mainline and was now taken by Debian Bullseye the last couple of
  days. RedHat and other distributions will probably run in the same problems,
  once they upgrade binutils.
- Linux perf and other applications build on these functionality are now
  doomed.

>binutils doesn't have any comitment to a stable ABI/API for libopcodes and
>libbfd.

Sure? They exposed bfd_get_section_flags and friends in bfd.h - it was not
hidden somewhere in private header files nor was it guarded by any other
measure. Correct me if I am wrong!

And: the functions/macros where used in the wild! They where helpful and
serviceable to the broader audience - which is (sorry: "was" :-) great!

The following patch fixed the problem for me to build Linux perf again:

--- /usr/include/bfd.h	2020-02-04 15:24:36.746534674 +0000
+++ /usr/include/bfd.new.h	2020-02-04 15:24:39.486542126 +0000
@@ -1243,6 +1243,11 @@
   return (sec->flags & SEC_IS_COMMON) != 0;
 }

+#define bfd_get_section_flags(bfd, ptr) ((void) bfd, (ptr)->flags)
+#define bfd_get_section_userdata(bfd, ptr) ((void) bfd, (ptr)->userdata)
+#define bfd_get_section_vma(bfd, ptr) ((void) bfd, (ptr)->vma)
+#define bfd_get_section_size(ptr) ((ptr)->size)
+


Note: for binutils ./bfd/bfd-in.h should be adjusted - sure.

Hagen Paul Pfeifer

>> It seems other people (kernel folks, Stephen) have the identical error as
>> well: https://lkml.org/lkml/2020/1/30/1005
>> Stephen: or is the bug fixed somewhere else? Do you have an workaround?a
>
>I don't have a work-around. If you rely on binutils internals, you really should
>adjust to binutils upstream.