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)

[Michael Stahl]

On 12/03/12 15:09, Lubos Lunak wrote:
> 
>  Windows/MSVC experts
> 
> On Monday 12 of March 2012, Stephan Bergmann wrote:
>> On 03/10/2012 04:39 PM, Lubos Lunak wrote:
>>> commit 34f8495dd948e2ad9d64c2c19110e69840cefd1a
>>> Author: Luboš Luňák<l.lunak at suse.cz>
>>> Date:   Sat Mar 10 15:37:02 2012 +0100
>>>
>>>      exported templates need to be marked as such
>>>
>>>      Otherwise their instances created in other modules may end up
>>>      as non-exported even when used by something exported.
>>>
>>> diff --git a/cppuhelper/inc/cppuhelper/compbase.hxx
>>> b/cppuhelper/inc/cppuhelper/compbase.hxx index 60e99ee..e590412 100644
>>> --- a/cppuhelper/inc/cppuhelper/compbase.hxx
>>> +++ b/cppuhelper/inc/cppuhelper/compbase.hxx
>>> @@ -41,7 +41,7 @@
>>>   namespace cppu \
>>>   { \
>>>   template<  __CLASS_IFC##N>  \
>>> -class SAL_NO_VTABLE WeakComponentImplHelper##N \
>>> +class SAL_NO_VTABLE CPPUHELPER_DLLPUBLIC WeakComponentImplHelper##N \
>>>
>>>       : public ::cppu::WeakComponentImplHelperBase \
>>>
>>>       , public ImplHelperBase##N<  __IFC##N>  \
>>>   { \
>>
>> Does this workaround for <http://llvm.org/bugs/show_bug.cgi?id=10113>
>> (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. So in general I think templates 
> need to be exported (also look e.g. at STL headers, which export the entire 
> std namespace, although I can see that Qt templates don't).
> 
>> work well with MSVC?  I wonder because there all consumers of the
>> template (outside of cppuhelper) will see it as __declspec(dllimport),
>> and (as long as there is no instantiation in cppuhelper) there is no
>> place that would emit it as __declspec(dllexport).
> 
>  I don't know about MSVC. Meaning that I haven't tried and I don't know how 
> export/import works on Windows anyway.

>  But it doesn't make much sense to me. It is not actually the template itself 
> that is or is not exported, because that's just a compile-time concept, but 
> it's instances of it as binary concept that are exported. And how does 
> something know whether some other library does or does not contain Foo< int > 
> without actually looking?

applying logic to how C++ features interact with linkers on various
platforms is generally a futile endeavour.

>  Assuming that this commit really breaks it on MSVC and the proper change 
> there is to remove the DLLPUBLIC from the template and hope the compiler and 
> linker sort it out somehow, then I guess we'll need to add 
> SAL_TEMPLATE_DLLPUBLIC which does nothing with MSVC and the right thing with 
> gcc/clang.

Voreppe tinderbox is already complaining rather loudly...

>  MSDN article on the dllimport/dllexport flags feels like it doesn't actually 
> say anything, but reading http://support.microsoft.com/kb/132044/en-us makes 
> me think the flags are just optimizations, so nothing will break. But 
> according to it SAL_TEMPLATE_DLLPUBLIC would be the right thing.

i recommend the following to understand the mess you got yourself into
(link to archive.org because original has been purged):

http://web.archive.org/web/20100504161204/http://blogs.sun.com/GullFOSS/entry/why_some_compilers_suck_more