From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 86461 invoked by alias); 4 Feb 2020 15:36:17 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Received: (qmail 86446 invoked by uid 89); 4 Feb 2020 15:36:16 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-12.6 required=5.0 tests=BAYES_00,GIT_PATCH_2,GIT_PATCH_3,KAM_SHORT,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 spammy=H*r:105, audience, wild, H*i:sk:d91b6b9 X-HELO: mout-p-101.mailbox.org Received: from mout-p-101.mailbox.org (HELO mout-p-101.mailbox.org) (80.241.56.151) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 04 Feb 2020 15:36:15 +0000 Received: from smtp1.mailbox.org (smtp1.mailbox.org [IPv6:2001:67c:2050:105:465:1:1:0]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by mout-p-101.mailbox.org (Postfix) with ESMTPS id 48Bpgw3hGrzKmcW; Tue, 4 Feb 2020 16:36:12 +0100 (CET) Received: from smtp1.mailbox.org ([80.241.60.240]) by spamfilter04.heinlein-hosting.de (spamfilter04.heinlein-hosting.de [80.241.56.122]) (amavisd-new, port 10030) with ESMTP id GJ0jwjgYtB_I; Tue, 4 Feb 2020 16:36:00 +0100 (CET) Date: Tue, 04 Feb 2020 15:36:00 -0000 From: Hagen Paul Pfeifer To: Matthias Klose Cc: 950414@bugs.debian.org, Ben Hutchings , Stephen Rothwell , Arnaldo Carvalho de Melo , binutils , gdb@sourceware.org, Alan Modra , "H.J. Lu" , Nick Clifton Subject: Re: Bug#950414: binutils-dev: failed to build linux perf (tools/perf) due to missing functions Message-ID: <20200204153557.GA280113@virgo> References: <20200201095306.GD9786@laniakea> <005fbdf3-a9c6-36d8-c2e8-0d307de5a40d@debian.org> <20200203210310.GA217509@virgo> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Key-Id: 98350C22 X-Key-Fingerprint: 490F 557B 6C48 6D7E 5706 2EA2 4A22 8D45 9835 0C22 X-GPG-Key: gpg --recv-keys --keyserver wwwkeys.eu.pgp.net 98350C22 X-SW-Source: 2020-02/txt/msg00014.txt.bz2 * 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.