Elimitate duplication of get_catalogs in different abi

Jonathan Wakely jwakely@redhat.com
Fri Sep 25 15:41:00 GMT 2015

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 <frs.dumont@gmail.com>:
>>>> 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


More information about the Gcc-patches mailing list