From: Hagen Paul Pfeifer <hagen@jauu.net>
To: Matthias Klose <doko@debian.org>
Cc: 950414@bugs.debian.org, Ben Hutchings <ben@decadent.org.uk>,
Stephen Rothwell <sfr@canb.auug.org.au>,
Arnaldo Carvalho de Melo <arnaldo.melo@gmail.com>,
binutils <binutils@sourceware.org>,
gdb@sourceware.org, Alan Modra <amodra@gmail.com>,
"H.J. Lu" <hjl.tools@gmail.com>, Nick Clifton <nickc@redhat.com>
Subject: Re: Bug#950414: binutils-dev: failed to build linux perf (tools/perf) due to missing functions
Date: Tue, 04 Feb 2020 15:36:00 -0000 [thread overview]
Message-ID: <20200204153557.GA280113@virgo> (raw)
In-Reply-To: <d91b6b94-c326-b972-483d-f586fb8a0d4b@debian.org>
* 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.
next parent reply other threads:[~2020-02-04 15:36 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20200201095306.GD9786@laniakea>
[not found] ` <005fbdf3-a9c6-36d8-c2e8-0d307de5a40d@debian.org>
[not found] ` <20200203210310.GA217509@virgo>
[not found] ` <d91b6b94-c326-b972-483d-f586fb8a0d4b@debian.org>
2020-02-04 15:36 ` Hagen Paul Pfeifer [this message]
2020-02-04 22:04 ` Romain Naour
2020-02-04 23:29 ` Alan Modra
2020-02-04 23:48 ` Ben Hutchings
2020-02-05 8:35 ` Thomas Backlund
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=20200204153557.GA280113@virgo \
--to=hagen@jauu.net \
--cc=950414@bugs.debian.org \
--cc=amodra@gmail.com \
--cc=arnaldo.melo@gmail.com \
--cc=ben@decadent.org.uk \
--cc=binutils@sourceware.org \
--cc=doko@debian.org \
--cc=gdb@sourceware.org \
--cc=hjl.tools@gmail.com \
--cc=nickc@redhat.com \
--cc=sfr@canb.auug.org.au \
/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