Re: Ambiguities in version script

[Ian Lance Taylor <iant at google dot com>]

Paolo Carlini <paolo.carlini@oracle.com> writes:

>> Does anybody want to argue that it is a good idea for the version
>> script to work this way?  Or should I send in a patch to change it?
>
> I suspect this issue is due to the sadly 'famous' here oversight a few
> years ago where we started to export some new symbols with an old
> version number, instead of the current one. As you may imagine, the
> users experienced some weird link error messages. Then Jakub helped
> sorting out the issue, for sure he knows better than me the details of
> his fix, I'm afraid some (minor) problems cannot be fixed completely
> at this time without breaking the abi.
>
> So... I would say, if you are fully aware of the specific issue I
> mentioned above, then go ahead with proposing a linker script patch,
> otherwise, if you need technical details first ask Jakub

The way a linker uses a version script is to say "given this symbol
with no version, what version should I use?"  In other words, a
version script assigns a unique version to a symbol.  So it's hard to
understand what it means to list a symbol multiple times in a version
script.


The GNU linker picks the first symbol that it finds.  So this is a
simple patch which produces the same results as the current linker
script:

Index: abi/pre/gnu.ver
===================================================================
--- abi/pre/gnu.ver	(revision 155510)
+++ abi/pre/gnu.ver	(working copy)
@@ -802,7 +802,8 @@ GLIBCXX_3.4.4 {
 GLIBCXX_3.4.5 {
 
     # std::string
-    _ZNKSs11_M_disjunctEPKc;
+    # This symbol has two versions.
+    #_ZNKSs11_M_disjunctEPKc;
     _ZNKSs15_M_check_lengthE[jmy][jmy]PKc;
     _ZNSs4_Rep26_M_set_length_and_sharableE*;
     _ZNSs7_M_copyEPcPKc[jmy];
@@ -810,7 +811,8 @@ GLIBCXX_3.4.5 {
     _ZNSs9_M_assignEPc[jmy]c;
 
     # std::wstring
-    _ZNKSbIwSt11char_traitsIwESaIwEE11_M_disjunctEPKw;
+    # This symbol has two versions.
+    #_ZNKSbIwSt11char_traitsIwESaIwEE11_M_disjunctEPKw;
     _ZNKSbIwSt11char_traitsIwESaIwEE15_M_check_lengthE[jmy][jmy]PKc;
     _ZNSbIwSt11char_traitsIwESaIwEE4_Rep26_M_set_length_and_sharableE*;
     _ZNSbIwSt11char_traitsIwESaIwEE7_M_copyEPwPKw[jmy];
@@ -839,7 +841,8 @@ GLIBCXX_3.4.6 {
 
     _ZNSt15basic_stringbufI[cw]St11char_traitsI[cw]ESaI[cw]EE9showmanycEv;
 
-    _ZNKSt15basic_stringbufIwSt11char_traitsIwESaIwEE3strEv;
+    # This is in GLIBCXX_3.4.
+    #_ZNKSt15basic_stringbufIwSt11char_traitsIwESaIwEE3strEv;
 
     _ZN9__gnu_cxx6__poolILb1EE13_M_initializeEv;
 



But this patch is a little odd, because, at least for the M_disjunct
cases, I am commenting out the current version of the symbol.  That
version is coming from compatibility.cc.  If I comment out the old
listing for the symbol, then the GNU linker drops the hidden
GLIBCXX_3.4 versions of the symbols, even though they are present in
compatibility.cc.  This happens because when the GNU linker finds a
version associated with a symbol, it looks it up in that specific
version in the version script to see whether it should be global or
local.  GLIBCXX_3.4 has a wildcard match for all symbols to force them
to be local.

Needless to say, none of this behaviour is documented.

So I guess I have to figure out whether to make gold act like the GNU
linker, even though it doesn't make much sense.

I guess my only comment for now about the libstdc++ version script is
that it lists _ZNKSt15basic_stringbufIwSt11char_traitsIwESaIwEE3strEv
twice, and that is pointless.  Only the first version of that symbol,
the one in GLIBCXX_3.4, will be used.

Ian