Description
The symbol in question is from gutil/strings/stringpiece.cc:
#include <ext/hash_set> namespace __gnu_cxx { size_t hash<StringPiece>::operator()(StringPiece s) const { return HashTo32(s.data(), s.size()); } } // namespace __gnu_cxx
Here is how readelf --syms sees it:
libkudu_client-clang342.so 22432: 00000000001ca230 63 FUNC LOCAL DEFAULT 10 _ZNK9__gnu_cxx4hashI11StringPieceEclES1_ libkudu_client-gcc446-el62.so 1019: 000000000021db6c 70 FUNC GLOBAL DEFAULT 11 _ZNK9__gnu_cxx4hashI11StringPieceEclES1_ 30110: 000000000021db6c 70 FUNC GLOBAL DEFAULT 11 _ZNK9__gnu_cxx4hashI11StringPieceEclES1_ libkudu_client-gcc447-el64.so 1022: 000000000021e8c0 70 FUNC GLOBAL DEFAULT 11 _ZNK9__gnu_cxx4hashI11StringPieceEclES1_ 30057: 000000000021e8c0 70 FUNC GLOBAL DEFAULT 11 _ZNK9__gnu_cxx4hashI11StringPieceEclES1_ libkudu_client-gcc482-trusty.so 21286: 00000000001c5a90 75 FUNC LOCAL HIDDEN 12 _ZNK9__gnu_cxx4hashI11StringPieceEclES1_
Notice how only gcc48 really gets the visibility right (making it both local and hidden), though clang34 at least makes it local. Older versions of gcc make it both global and default, which means client_symbol-test flags it as a bad symbol (because it can be used by applications that link libkudu_client.so). I suspect a gcc visibility-related bug, but having looked at several I can't figure out which one.
For the time being I'm going to make the exported client build use clang34, but I'm leaving this bug report open for further investigation.