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. > 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 ;-) Thanks. Rainer -- ----------------------------------------------------------------------------- Rainer Orth, Center for Biotechnology, Bielefeld University