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<[email protected]> >>> 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 _______________________________________________ LibreOffice mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/libreoffice
