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)
sbergman at redhat.com
Mon Mar 12 11:03:09 PDT 2012
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
>> (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",
in combination with "Most everything in this section [on vague linkage]
also applies to template instantiations"
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
> (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).
More information about the LibreOffice