From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 57736 invoked by alias); 25 Sep 2015 15:10:56 -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 57716 invoked by uid 89); 25 Sep 2015 15:10:56 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 X-Spam-User: qpsmtpd, 2 recipients X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Fri, 25 Sep 2015 15:10:55 +0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (Postfix) with ESMTPS id 23E6DC0B2E08; Fri, 25 Sep 2015 15:10:54 +0000 (UTC) Received: from localhost (ovpn-116-138.ams2.redhat.com [10.36.116.138]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t8PFAqkE001500; Fri, 25 Sep 2015 11:10:52 -0400 Date: Fri, 25 Sep 2015 15:46:00 -0000 From: Jonathan Wakely To: =?iso-8859-1?Q?Fran=E7ois?= Dumont Cc: "libstdc++@gcc.gnu.org" , gcc-patches Subject: Re: Elimitate duplication of get_catalogs in different abi Message-ID: <20150925151052.GI12094@redhat.com> References: <55B694F5.3070606@gmail.com> <55BA81B1.9030206@gmail.com> <20150805205744.GC13355@redhat.com> <55D79415.90600@gmail.com> <55EB586A.8080405@gmail.com> <5602FD59.2020805@gmail.com> <20150925150833.GH12094@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20150925150833.GH12094@redhat.com> X-Clacks-Overhead: GNU Terry Pratchett User-Agent: Mutt/1.5.23 (2014-03-12) X-SW-Source: 2015-09/txt/msg01982.txt.bz2 On 25/09/15 16:08 +0100, Jonathan Wakely wrote: >On 23/09/15 21:28 +0200, François Dumont wrote: >>On 05/09/2015 23:02, François Dumont wrote: >>>On 22/08/2015 14:24, Daniel Krügler wrote: >>>>2015-08-21 23:11 GMT+02:00 François Dumont : >>>>>I think I found a better way to handle this problem. It is c++locale.cc >>>>>that needs to be built with --fimplicit-templates. I even think that the >>>>>*_cow.cc file do not need this option but as I don't know what is the >>>>>drawback of this option I kept it. I also explicitely used the file name >>>>>c++locale.cc even if it is an alias to a configurable source file. I >>>>>guess there must be some variable to use no ? >>>>> >>>>>With this patch there are 6 additional symbols. I guess I need to >>>>>declare those in the scripts even if it is for internal library usage, >>>>>right ? >>>>I would expect that the new Catalog_info definition either has deleted >>>>or properly (user-)defined copy constructor and copy assignment >>>>operator. >>>> >>>> >>>>- Daniel >>>> >>>This type is used in C++98 so I need to make those private, not deleted. >>> >>>With this change, is the patch ok to commit ? >>> >>>François >>> >> >>What about this patch ? >> >>I am still uncomfortable in exposing those implementation details in the >>versionned symbols but I don't know how to do otherwise. Do you want me >>to push this code in std::__detail namespace ? > >I think because the types are only used internally in the library we >don't need to export them. The other code inside the shared library >can refer to those symbols without them being exported. > >That way users can't see their names (because they're not in any >public headers) and can't use the symbols (because they're not >exported) so they're pure internal implementation details. > >I tested it briefly and it seems to work, so if you can confirm it >still works then the patch is OK without the changes to gnu.ver Oh, the problem is that the symbols are matched by patterns in the _GLIBCXX_3.4 version, so get exported with that version instead. Gah. In that case your patch would not have worked on Solaris anyway, as the SOlaris linker gives an error if a symbol matches patterns in more than one symbol version. Let me try to adjust the gnu.ver script to make this work ...