Current mozc ebuild is using in-tree protobuf source which is unpacked in the src_unpack phase, so it should not require protobuf from system. (I saw that there's "use_libprotobuf=1" in the ebuild, but it is commented out.) Thus, I suggest dropping "~dev-libs/protobuf-2.4.1" dependency from the ebuild.
As per bug #251464 using the internal version is contrary to current QA policy.
(In reply to Jeroen Roovers from comment #1) > As per bug #251464 using the internal version is contrary to current QA > policy. Oops, I didn't know that. Thank you for pointing it out. I'll keep in mind that I should avoid using internal library. However, the change was done according to this upstream bug: https://code.google.com/p/mozc/issues/detail?id=14 And this upstream revision: https://code.google.com/p/mozc/source/detail?r=96 (see also Gentoo bug #407581) They switched from linking shared protobuf to linking static protobuf by default in that version, so I followed that change. It seems that linking to shared protobuf library causes some issue in mozc, but I haven't encountered one personally when mozc was still using shared protobuf by default (I'm using mozc with ibus). The example given in the bug is related to uim-mozc. I can't find uim-mozc support in current mozc ebuild. If uim-mozc gets supported in the future, this issue may appear. I'd like to know how such confliction (between QA policy and upstream default) should be solved.
I see there's bug 478094 which is fixed now. Should I close this one also?
*** This bug has been marked as a duplicate of bug 478094 ***
