[
https://issues.apache.org/jira/browse/KUDU-455?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Todd Lipcon resolved KUDU-455.
------------------------------
Resolution: Won't Fix
Fix Version/s: n/a
A while back we switched to requiring gcc 4.9 which doesn't have this problem.
> Older gcc adds unexpected global+default symbol to libkudu_client.so
> --------------------------------------------------------------------
>
> Key: KUDU-455
> URL: https://issues.apache.org/jira/browse/KUDU-455
> Project: Kudu
> Issue Type: Bug
> Components: client
> Affects Versions: M4.5
> Reporter: Adar Dembo
> Priority: Trivial
> Fix For: n/a
>
>
> The symbol in question is from gutil/strings/stringpiece.cc:
> {code}
> #include <ext/hash_set>
> namespace __gnu_cxx {
> size_t hash<StringPiece>::operator()(StringPiece s) const {
> return HashTo32(s.data(), s.size());
> }
> } // namespace __gnu_cxx
> {code}
> Here is how readelf --syms sees it:
> {noformat}
> 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_
> {noformat}
> 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.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
