Re: [v3 PATCH] Implement LWG 2221, No formatted output operator for nullptr

[Jonathan Wakely <jwakely@redhat.com>]

On 11/01/19 10:07 +0100, Rainer Orth wrote:
>Hi Jonathan,
>
>>>this patch broke Solaris bootstrap:
>>>
>>>ld: fatal: libstdc++-symbols.ver-sun: 7117: symbol 'std::basic_ostream<char, std::char_traits<char> >::operator<<(decltype(nullptr))': symbol version conflict
>>>ld: fatal: libstdc++-symbols.ver-sun: 7119: symbol 'std::basic_ostream<wchar_t, std::char_traits<wchar_t> >::operator<<(decltype(nullptr))': symbol version conflict
>>>
>>>ld: fatal: libstdc++-symbols.ver-sun: 7117: symbol '_ZNSolsEDn': symbol version conflict
>>>ld: fatal: libstdc++-symbols.ver-sun: 7119: symbol '_ZNSt13basic_ostreamIwSt11char_traitsIwEElsEDn': symbol version conflict
>>>
>>>Again, there were two matches for those two symbols:
>>>
>>>  GLIBCXX_3.4
>>>    ##_ZNSolsE*[^Dg] (glob)
>>>    _ZNSolsEDn;
>>>  GLIBCXX_3.4.26
>>>    ##_ZNSolsEDn (glob)
>>>    _ZNSolsEDn;
>>>
>>>  GLIBCXX_3.4
>>>    ##_ZNSt13basic_ostreamIwSt11char_traitsIwEElsE*[^Dg] (glob)
>>>    _ZNSt13basic_ostreamIwSt11char_traitsIwEElsEDn;
>>>  GLIBCXX_3.4.26
>>>    ##_ZNSt13basic_ostreamIwSt11char_traitsIwEElsEDn (glob)
>>>    _ZNSt13basic_ostreamIwSt11char_traitsIwEElsEDn;
>>>
>>>ISTM that the patterns were backwards.  The following patch fixes this
>>>and allowed i386-pc-solaris2.11 bootstrap to complete without
>>>regressions relative to the last successful one.
>>
>> I think what I should have done is change [^g] to [^gn]. That
>> preserves the original behaviour (don't match the ppc64 long double
>> symbols) but also excludes the new symbols, which end in 'n'.
>>
>> Maybe the attached patch would be better though. It matches every
>> basic_ostream::operator<<(T) for any scalar T except 'g', and adds a
>> second pattern to match basic_ostream::operator<<(T*) for various T.
>> But neither of those matches the new operator<<(nullptr_t) overload.
>
>it allowed me to link libstdc++.so, too.  For my patch I'd only been
>going from the ld errors and the matching patterns in the generated
>libstdc++.map-sun, not knowing the background here.

THanks for checking it. I've committed the patch now.

>> FWIW I did run my symbol checker script, but it gets lots of false
>> positives because it doesn't understand the #if preprocessor
>> conditions, so it sees lots of false positive duplicates. I need to
>> make it smarter for it to be useful here.
>
>Indeed: the variation possible here can be a total PITA ;-)

I've managed to cobble together a pipeline with sed and cpp that
allows me to test the linker script properly. It found some conflicts
that still remain but presumably aren't present on Solaris because
HAVE_SYMVER_SYMBOL_RENAMING_RUNTIME_SUPPORT is not defined.

There's one remaining conflict, which https://gcc.gnu.org/PR88125
covers. 

I'll commit a patch for those shortly.