Re: Elimitate duplication of get_catalogs in different abi

[Jonathan Wakely <jwakely at redhat dot com>]

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

diff --git a/libstdc++-v3/config/abi/pre/gnu.ver b/libstdc++-v3/config/abi/pre/gnu.ver
index d42cd37..c761052 100644
--- a/libstdc++-v3/config/abi/pre/gnu.ver
+++ b/libstdc++-v3/config/abi/pre/gnu.ver
@@ -24,7 +24,7 @@ GLIBCXX_3.4 {
     # Names inside the 'extern' block are demangled names.
     extern "C++"
     {
-      std::[A-Z]*;
+      std::[ABD-Z]*;
       std::a[a-c]*;
       std::ad[a-n]*;
       std::ad[p-z]*;
@@ -106,7 +106,7 @@ GLIBCXX_3.4 {
 #     std::istringstream*;
       std::istrstream*;
       std::i[t-z]*;
-      std::[A-Zj-k]*;
+      std::[j-k]*;
 #     std::length_error::l*;
 #     std::length_error::~l*;
       std::locale::[A-Za-e]*;
@@ -132,9 +132,8 @@ GLIBCXX_3.4 {
 #     std::logic_error::l*;
       std::logic_error::what*;
 #     std::logic_error::~l*;
-#     std::[A-Zm-r]*;
-#     std::[A-Zm]*;
-      std::[A-Z]*;
+#     std::[m-r]*;
+#     std::[m]*;
       std::messages[^_]*;
 #     std::messages_byname*;
       std::money_*;
@@ -175,11 +174,13 @@ GLIBCXX_3.4 {
 #     std::t[i-n]*;
       std::tr1::h[^a]*;
       std::t[s-z]*;
-#     std::[A-Zu-z]*;
+#     std::[u-z]*;
 #     std::underflow_error::u*;
 #     std::underflow_error::~u*;
       std::unexpected*;
-      std::[A-Zv-z]*;
+      std::valarray*;
+      # std::vector*
+      std::[w-z]*;
       std::_List_node_base::hook*;
       std::_List_node_base::swap*;
       std::_List_node_base::unhook*;