Elimitate duplication of get_catalogs in different abi

[Jonathan Wakely]

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 <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

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 ...