Exporting templates on Windows (Re: [Libreoffice-commits] .: 7 commits - clucene/patches clucene/source configure.in cppuhelper/inc hwpfilter/source sal/inc solenv/gbuild vbahelper/inc)

[Stephan Bergmann]

On 03/12/2012 03:09 PM, Lubos Lunak wrote:
>> Does this workaround for<http://llvm.org/bugs/show_bug.cgi?id=10113>

...should have been <http://llvm.org/bugs/show_bug.cgi?id=11250> "no 
code emitted for virtual inline function inherited indirectly from class 
template"

>> (where I'm still not convinced it is a user error vs. a compiler error)
>
>   I am rather convinced that the original issue
> (without -fvisibility-inlines-hidden) is a user error, so I consider this to
> be a proper fix rather than a workaround.
>
>   Imagine for example that the template has a static data member - that one
> would need to be merged to be just in one place, and that just wouldn't work
> if the template was public API but hidden.

I see no fundamental reason why that should not work.  I would argue 
that the compiler could still export that symbol with some form of vague 
linkage, as it does if the template is not hidden.  But I just see that 
GCC does not do that, and even somewhat specifies that it does not do 
that ("type visibility is applied to vague linkage entities associated 
with the class", 
<http://gcc.gnu.org/onlinedocs/gcc-4.6.3/gcc/Type-Attributes.html#Type-Attributes> 
in combination with "Most everything in this section [on vague linkage] 
also applies to template instantiations" 
<http://gcc.gnu.org/onlinedocs/gcc-4.6.3/gcc/Vague-Linkage.html#Vague-Linkage>).

Looks like a misunderstanding whether hidden visibility is intended for 
"remove unnecessary entries from dynamic symbol tables (but keeping 
certain symbols exported to not violate certain standard requirements)" 
or "allow violations of ODR by hiding classes completely from dynamic 
symbol tables."  I had naively assumed the former, while compiler 
writers apparently use the latter interpretation.

> So in general I think templates need to be exported

I guess general reluctance against that insight in LO stems from LO 
being cross-platform, and the Windows dllimport/export model being 
substantially different from the GCC/ELF visibility model, and not 
marking (all-inline) templates for neither dllimport/export nor default 
visibility was the only approach that did work across all compilers, 
MSVC, GCC, and Sun.  (If only worked sort of, see Michael's link to 
<http://web.archive.org/web/20100504161204/http://blogs.sun.com/GullFOSS/entry/why_some_compilers_suck_more>.)

> (also look e.g. at STL headers, which export the entire std namespace,

Not sure what you mean here.  At least with Fedora GCC 4.6, (all-inline) 
std class templates are not visibility-attributed (so would cause the 
problems discussed at <http://llvm.org/bugs/show_bug.cgi?id=11250> if 
client code derived from them).

Stephan