This is the mail archive of the
gcc-help@gcc.gnu.org
mailing list for the GCC project.
ELF symbol visibility vs. member function template instantiations
- From: "Schneider, Robert" <robert dot schneider03 at sap dot com>
- To: "gcc-help at gcc dot gnu dot org" <gcc-help at gcc dot gnu dot org>
- Date: Tue, 30 Aug 2016 11:16:28 +0000
- Subject: ELF symbol visibility vs. member function template instantiations
- Authentication-results: sourceware.org; auth=none
Hi,
Consider a free function template
template<typename T>
void __attribute__((visibility("default"))) free_func();
that is instantiated with a type that is hidden:
struct __attribute__((visibility("hidden"))) HiddenType {};
then the resulting function template instantiation free_func<HiddenType> is hidden as well.
However, when I do the same with a member function template of a visible class:
struct __attribute__((visibility("default"))) OuterClass
{
template<typename T>
void __attribute__((visibility("default"))) member_func();
};
then the resulting member function template instantiation OuterClass::member_func<HiddenType> is visible.
If OuterClass however is hidden, then OuterClass::member_func<HiddenType> is hidden as well.
==> Why does the visibility of member function template instantiations depend on the visibility of the class? <==
Namespace visibility doesn't affect free function templates in the same way.
clang by the way hides OuterClass::member_func<HiddenType> independently of the visibility of OuterClass.
I've stumbled upon this behaviour when working with facets (of std::locale), which are used by libstdc++ both from free function templates and member function templates.
When the facet type is hidden but used in multiple shared objects, problems arise because only some of the libstdc++ function template instantiations are visible and those get interposed.
This causes problems with identification of the facets via std::locale::id.
(I know how to solve those issues, I'm more interested in what causes them.)
Thanks and kind regards,
Robert