This is the mail archive of the
mailing list for the GCC project.
Re: Elimitate duplication of get_catalogs in different abi
- From: Jonathan Wakely <jwakely at redhat dot com>
- To: François Dumont <frs dot dumont at gmail dot com>
- Cc: "libstdc++ at gcc dot gnu dot org" <libstdc++ at gcc dot gnu dot org>, gcc-patches <gcc-patches at gcc dot gnu dot org>
- Date: Fri, 25 Sep 2015 16:10:52 +0100
- Subject: Re: Elimitate duplication of get_catalogs in different abi
- Authentication-results: sourceware.org; auth=none
- References: <55B694F5 dot 3070606 at gmail dot com> <55BA81B1 dot 9030206 at gmail dot com> <20150805205744 dot GC13355 at redhat dot com> <55D79415 dot 90600 at gmail dot com> <CAGNvRgBW8Yzj7_XG5DJfBdsLa0yhgZViEW=vAd7ijwZq9PVVag at mail dot gmail dot com> <55EB586A dot 8080405 at gmail dot com> <5602FD59 dot 2020805 at gmail dot com> <20150925150833 dot GH12094 at redhat dot com>
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 <firstname.lastname@example.org>:
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,
I would expect that the new Catalog_info definition either has deleted
or properly (user-)defined copy constructor and copy assignment
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 ?
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 ...