Elimitate duplication of get_catalogs in different abi

[Jonathan Wakely]

On 25/09/15 16:10 +0100, Jonathan Wakely wrote:
>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 ...

This should do it ...

-------------- next part --------------
A non-text attachment was scrubbed...
Name: patch.txt
Type: text/x-patch
Size: 1409 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/libstdc++/attachments/20150925/38c29ab4/attachment.bin>