Elimitate duplication of get_catalogs in different abi

[François Dumont]

On 25/09/2015 17:58, Jonathan Wakely wrote:
> 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 ...
>
Indeed, I just rerun all tests with success. I am re-attaching the patch.

2015-09-30  François Dumont  <fdumont@gcc.gnu.org>
        Jonathan Wakely  <jwakely@redhat.com>

    * config/locale/gnu/messages_members.cc (Catalog_info, Catalogs):
    Move...
    * config/locale/gnu/c++locale_internal.h: ...here in std namespace.
    * config/locale/gnu/c_locale.cc: Move implementation of latter here.
    * config/abi/pre/gnu.ver: Adjust.

Ok to commit ?

François

-------------- next part --------------
A non-text attachment was scrubbed...
Name: messages_catalogs.patch
Type: text/x-patch
Size: 12133 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/gcc-patches/attachments/20150929/2172a1aa/attachment.bin>