From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 68300 invoked by alias); 16 Jul 2019 14:27:20 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 68286 invoked by uid 89); 16 Jul 2019 14:27:20 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 spammy=aforementioned, H*Ad:U*neroden, H*r:0700, our X-HELO: relay1.mentorg.com Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 16 Jul 2019 14:27:18 +0000 Received: from svr-orw-mbx-02.mgc.mentorg.com ([147.34.90.202]) by relay1.mentorg.com with esmtps (TLSv1.2:ECDHE-RSA-AES256-SHA384:256) id 1hnOQF-0000Mw-PW from ChungLin_Tang@mentor.com ; Tue, 16 Jul 2019 07:27:15 -0700 Received: from [0.0.0.0] (147.34.91.1) by svr-orw-mbx-02.mgc.mentorg.com (147.34.90.202) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Tue, 16 Jul 2019 07:27:11 -0700 Reply-To: Subject: Re: [PR other/79543] Fix GNU ld --version scanning to conform to the GNU Coding Standards (ping) From: Chung-Lin Tang To: Joseph Myers , Thomas Schwinge CC: , Paolo Bonzini , DJ Delorie , Nathanael Nerode , Alexandre Oliva , Ralf Wildenhues References: <87po9jhz9e.fsf@euler.schwinge.homeip.net> <1f4fb5d4-a76b-c59d-39fb-c59805590610@mentor.com> Message-ID: <413a4c2c-b895-31a4-e4ab-37c6c519ed56@mentor.com> Date: Tue, 16 Jul 2019 14:45:00 -0000 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.7.2 MIME-Version: 1.0 In-Reply-To: <1f4fb5d4-a76b-c59d-39fb-c59805590610@mentor.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit X-SW-Source: 2019-07/txt/msg01121.txt.bz2 Ping. (I think Joseph happens to be out, was wondering if any build maintainer or global reviewer can take a look?) Thanks, Chung-Lin On 2019/7/4 4:28 PM, Chung-Lin Tang wrote: > On 2017/10/31 8:17 AM, Joseph Myers wrote: >> Specifically,*non-release*  versions of binutils predating my patch >> >> commit 066c2a57f5858310c9f12518317aecd4b54e753d >> Author: Joseph Myers >> Date:   Thu Mar 1 15:48:36 2007 +0000 >> >> would have had a space between the binutils version number and the BFD >> datestamp and the end of the first line of --version output.  That would >> not have been an issue for release versions, and the stray word "version" >> before the version number before that patch would not cause problems for >> the simplified sed expressions. >> >>> Applying the following patch (that is, simplying the sed command), makes >>> the problem go away: >>> >>>      -sed -e 's/GNU gold /GNU ld /;s/GNU ld version /GNU ld /;s/GNU ld ([^)]*) /GNU ld /;s/GNU ld \([0-9.][0-9.]*\).*/\1/; q'` >>>      +sed -e 's/GNU gold /GNU ld /;s/GNU ld .* \(.*\)/\1/; q'` >> While I think working properly for binutils versions in the past ten years >> matters more than any issues with old non-release versions that probably >> wouldn't work with current GCC anyway, it seems to me that this patch >> would require*something*  surrounded by spaces between "GNU ld" and the >> version number.  If you configure with --without-pkgversion, you get e.g. >> >> GNU ld 2.28 >> >> as the complete first line of the output, and that doesn't look like it >> would match the above pattern, as there's only one space not two between >> "GNU ld" and the version number.  So I think you need a pattern that does >> allow the --without-pkgversion form of output. > > Bringing back this issue, as this is still bothering our OpenACC toolchains. > > If the main variance in format was the 2007 ' ' to '.' change for non-release > binutils builds, then is the attached patch okay? > > What the patch does is to first look for an 8-digit part at the end > (preceded by either a space or '.'), chop it off if it exists, and then take the last > space-preceded string. > > This matching logic does appear to be more reliant on the aforementioned > GNU standard of 'everything after the last space on the first line of the output'. > OTOH, not sure if all the testing for GNU gold, GNU ld, etc. in the current > sed pattern means much since this is already under $with_gnu_ld=yes. > > (seeking approval for trunk and all active release branches) > > Thanks, > Chung-Lin > > 2019-07-04  Chung-Lin Tang > >         libatomic/ >         PR other/79543 >         * acinclude.m4 (LIBAT_CHECK_LINKER_FEATURES): Fix GNU ld --version >         scanning to conform to the GNU Coding Standards. >         * configure: Regenerate. > >         libffi/ >         PR other/79543 >         * acinclude.m4 (LIBAT_CHECK_LINKER_FEATURES): Fix GNU ld --version >         scanning to conform to the GNU Coding Standards. >         * configure: Regenerate. > >         libgomp/ >         PR other/79543 >         * acinclude.m4 (LIBGOMP_CHECK_LINKER_FEATURES): Fix GNU ld --version >         scanning to conform to the GNU Coding Standards. >         * configure: Regenerate. > >         libitm/ >         PR other/79543 >         * acinclude.m4 (LIBITM_CHECK_LINKER_FEATURES): Fix GNU ld --version >         scanning to conform to the GNU Coding Standards. >         * configure: Regenerate. > >         libstdc++-v3/ >         PR other/79543 >         * acinclude.m4 (GLIBCXX_CHECK_LINKER_FEATURES): Fix GNU ld --version >         scanning to conform to the GNU Coding Standards. >         * configure: Regenerate.