From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) by sourceware.org (Postfix) with ESMTP id F22C83860C3E for ; Mon, 16 Nov 2020 10:37:33 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org F22C83860C3E Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-159-kZ8YhCipMSuc8n3_hi3pJg-1; Mon, 16 Nov 2020 05:37:30 -0500 X-MC-Unique: kZ8YhCipMSuc8n3_hi3pJg-1 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 21CAD801FDF; Mon, 16 Nov 2020 10:37:29 +0000 (UTC) Received: from localhost (unknown [10.33.36.170]) by smtp.corp.redhat.com (Postfix) with ESMTP id B6AA57664C; Mon, 16 Nov 2020 10:37:28 +0000 (UTC) Date: Mon, 16 Nov 2020 10:37:28 +0000 From: Jonathan Wakely To: Rainer Orth Cc: libstdc++@gcc.gnu.org, gcc-patches@gcc.gnu.org, Iain Sandoe Subject: Re: [PATCH] libstdc++: Fix error shown during Solaris build Message-ID: <20201116103728.GT503596@redhat.com> References: <20201113110735.GA505111@redhat.com> <20201116103240.GS503596@redhat.com> MIME-Version: 1.0 In-Reply-To: <20201116103240.GS503596@redhat.com> X-Clacks-Overhead: GNU Terry Pratchett X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline X-Spam-Status: No, score=-8.1 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H4, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2020 10:37:35 -0000 On 16/11/20 10:32 +0000, Jonathan Wakely wrote: >On 16/11/20 11:17 +0100, Rainer Orth wrote: >>Hi Jonathan, >> >>>Currently this is shown when building libstdc++ on Solaris: >>> >>>-lrt: open: No such file or directory >>> >>>The error comes from the make_sunver.pl script which tries to open each >>>of its arguments. The arguments are passed by this make rule: >>> >>> perl ${glibcxx_srcdir}/scripts/make_exports.pl \ >>> libstdc++-symbols.ver \ >>> $(libstdc___la_OBJECTS:%.lo=.libs/%.o) \ >>> `echo $(libstdc___la_LIBADD) | \ >>> sed 's,/\([^/.]*\)\.la,/.libs/\1.a,g'` \ >>> > $@ || (rm -f $@ ; exit 1) >>> >>>The $(libstdc___la_LIBADD) variable includes $(GLIBCXX_LIBS) which >>>contains -lrt on Solaris. >>> >>>This patch adds another sed script to filter -l arguments from the echo >>>command. In order to reliably match ' -l[^ ]* ' the echo arguments are >>>quoted and a space added before and after them. This might be overkill >>>just to remove -lrt from the start of the string, but should be robust >>>in case other -l arguments are added to $(GLIBCXX_LIBS), or in case the >>>$(libstdc___la_LIBADD) libraries are reordered. >>> >>>libstdc++-v3/ChangeLog: >>> >>> * src/Makefile.am (libstdc++-symbols.ver-sun): Remove -lrt from >>> arguments passed to make_sunver.pl script. >>> * src/Makefile.in: Regenerate. >>> >>>Tested sparc-solaris2.11. Rainer, does this look OK? >> >>it does, but let me give it a try with both GNU sed and Solaris sed: we >>had too many weird issues with the latter ;-( > >I think the machine I tested on (gcc211 in the compile farm) only has >Solaris sed in the PATH, and it works there. > >I did try to use "-l ?[[:alnum:]]+" but Solaris sed only supports BREs >(as POSIX requires) and there doesn't seem to be an equivalent of the >GNU sed -E option to use EREs. POSIX agreed to add the -E option 8 years ago but that hasn't made it into the standard yet (because we're still on POSIX 2011+TC1+TC2 and presumably have to wait for the next revision). https://www.austingroupbugs.net/view.php?id=528 https://pubs.opengroup.org/onlinepubs/9699919799/utilities/sed.html