Gold linker segfaults linking symbols with different versions.
The scenarios is explained below:
We have a symbol "_ZNKSs11_M_disjunctEPKc", defined in 3 different places:
a) - "_ZNKSs11_M_disjunctEPKc" in libstdc++.a(string-inst.pic.o)
b) - "_ZNKSs11_M_disjunctEPKc@GLIBCXX_3.4" in compatibility.pic.o
c) - "_ZNKSs11_M_disjunctEPKc@@GLIBCXX_3.4.5" in compatibility.pic.o
And we link with a version script file -
The problem we have is
1) - linker reads a), gets version "3.4" from version script file, thus it is treated as "default_version".
2) - linker reads c), get version "3.4.5", also regarded as default version, because of "@@".
3) - linker segfaults at Symbol::override_version.
We only circumvent this if linker processes symbols in the order of a) -> b) ->
c). However the order linker processes symbols is out of our control.
Is there an usage error - providing a default version in both version script file and object file?
But anyway, the link segfaul should be fixed.
(I think the explanation is clear to identify the problem, if not, I'll reduce what I have and provide a small test case)
I ran into this one again just now.
It may be worth explicitly noting that the failing case in question is "linking GNU libstdc++ with Gold" -- which doesn't really seem that esoteric a thing to want to do....