This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Elimitate duplication of get_catalogs in different abi


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]