From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2514 invoked by alias); 11 Jan 2019 09:07:59 -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 2496 invoked by uid 89); 11 Jan 2019 09:07:58 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-5.9 required=5.0 tests=BAYES_00,GIT_PATCH_2,KAM_LAZY_DOMAIN_SECURITY autolearn=ham version=3.3.2 spammy= X-HELO: smtp.CeBiTec.Uni-Bielefeld.DE Received: from smtp.CeBiTec.Uni-Bielefeld.DE (HELO smtp.CeBiTec.Uni-Bielefeld.DE) (129.70.160.84) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 11 Jan 2019 09:07:56 +0000 Received: from localhost (localhost.CeBiTec.Uni-Bielefeld.DE [127.0.0.1]) by smtp.CeBiTec.Uni-Bielefeld.DE (Postfix) with ESMTP id B4A921B; Fri, 11 Jan 2019 10:07:52 +0100 (CET) Received: from smtp.CeBiTec.Uni-Bielefeld.DE ([127.0.0.1]) by localhost (malfoy.CeBiTec.Uni-Bielefeld.DE [127.0.0.1]) (amavisd-new, port 10024) with LMTP id YwSIlMOYoC0s; Fri, 11 Jan 2019 10:07:50 +0100 (CET) Received: from lokon.CeBiTec.Uni-Bielefeld.DE (lokon.CeBiTec.Uni-Bielefeld.DE [129.70.161.152]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.CeBiTec.Uni-Bielefeld.DE (Postfix) with ESMTPS id 64A9A18; Fri, 11 Jan 2019 10:07:50 +0100 (CET) Received: (from ro@localhost) by lokon.CeBiTec.Uni-Bielefeld.DE (8.15.2+Sun/8.15.2/Submit) id x0B97mCH018286; Fri, 11 Jan 2019 10:07:48 +0100 (MET) From: Rainer Orth To: Jonathan Wakely Cc: Ville Voutilainen , libstdc++ , "gcc-patches\@gcc.gnu.org" Subject: Re: [v3 PATCH] Implement LWG 2221, No formatted output operator for nullptr References: <20171204230424.GA31922@redhat.com> <20190110131519.GC15627@redhat.com> <20190111000146.GE15627@redhat.com> Date: Fri, 11 Jan 2019 09:07:00 -0000 In-Reply-To: <20190111000146.GE15627@redhat.com> (Jonathan Wakely's message of "Fri, 11 Jan 2019 00:01:46 +0000") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (usg-unix-v) MIME-Version: 1.0 Content-Type: text/plain X-IsSubscribed: yes X-SW-Source: 2019-01/txt/msg00606.txt.bz2 Hi Jonathan, >>this patch broke Solaris bootstrap: >> >>ld: fatal: libstdc++-symbols.ver-sun: 7117: symbol 'std::basic_ostream >::operator<<(decltype(nullptr))': symbol version conflict >>ld: fatal: libstdc++-symbols.ver-sun: 7119: symbol 'std::basic_ostream >::operator<<(decltype(nullptr))': symbol version conflict >> >>ld: fatal: libstdc++-symbols.ver-sun: 7117: symbol '_ZNSolsEDn': symbol version conflict >>ld: fatal: libstdc++-symbols.ver-sun: 7119: symbol '_ZNSt13basic_ostreamIwSt11char_traitsIwEElsEDn': symbol version conflict >> >>Again, there were two matches for those two symbols: >> >> GLIBCXX_3.4 >> ##_ZNSolsE*[^Dg] (glob) >> _ZNSolsEDn; >> GLIBCXX_3.4.26 >> ##_ZNSolsEDn (glob) >> _ZNSolsEDn; >> >> GLIBCXX_3.4 >> ##_ZNSt13basic_ostreamIwSt11char_traitsIwEElsE*[^Dg] (glob) >> _ZNSt13basic_ostreamIwSt11char_traitsIwEElsEDn; >> GLIBCXX_3.4.26 >> ##_ZNSt13basic_ostreamIwSt11char_traitsIwEElsEDn (glob) >> _ZNSt13basic_ostreamIwSt11char_traitsIwEElsEDn; >> >>ISTM that the patterns were backwards. The following patch fixes this >>and allowed i386-pc-solaris2.11 bootstrap to complete without >>regressions relative to the last successful one. > > I think what I should have done is change [^g] to [^gn]. That > preserves the original behaviour (don't match the ppc64 long double > symbols) but also excludes the new symbols, which end in 'n'. > > Maybe the attached patch would be better though. It matches every > basic_ostream::operator<<(T) for any scalar T except 'g', and adds a > second pattern to match basic_ostream::operator<<(T*) for various T. > But neither of those matches the new operator<<(nullptr_t) overload. it allowed me to link libstdc++.so, too. For my patch I'd only been going from the ld errors and the matching patterns in the generated libstdc++.map-sun, not knowing the background here. > FWIW I did run my symbol checker script, but it gets lots of false > positives because it doesn't understand the #if preprocessor > conditions, so it sees lots of false positive duplicates. I need to > make it smarter for it to be useful here. Indeed: the variation possible here can be a total PITA ;-) Thanks. Rainer -- ----------------------------------------------------------------------------- Rainer Orth, Center for Biotechnology, Bielefeld University