Re: [PATCH] Fix for sw_filter_test crash due to ambiguous FieldEntry destructor

On 24/07/12 15:20, Stephan Bergmann wrote:
> On 07/23/2012 05:28 PM, Stephan Bergmann wrote:
> > On 07/23/2012 04:40 PM, Michael Stahl wrote:
> > > On 22/07/12 11:25, Kristian Rietveld wrote:
> > > > (Please keep me on CC as I am not subscribed to the list)
> > [...]
> > > that is really not supposed to happen, we really should build everything
> > > with -fvisibility=hidden on all platforms where unnecessarily exported
> > > symbols cause such problems (guess that means everything but Windows).
> > >
> > > on master and libreoffice-3-6, in solenv/gbuild/platform/macosx.mk the
> > > -fvisibility=hidden is inside:
> > >
> > > > ifeq ($(HAVE_GCC_VISIBILITY_FEATURE),TRUE)
> > >
> > > can you check that that is actually detected properly for your compiler?
> >
> > Explicitly disabled for Clang on Mac OS X in configure.in, see
> > <http://cgit.freedesktop.org/libreoffice/core/commit/?id=e5143062887093037cab8f936288af8408576ea8>
> > "Visibility doesn't seem to work as we want in Apple's Clang."  :(
>
> ....and if you revert that (leading to HAVE_GCC_VISIBILITY_FEATURE=TRUE 
> and HAVE_GCC_VISIBILITY_BROKEN=TRUE), the build starts to break as e.g. 
> libxolo.dylib contains 
> __ZN4cppu15WeakImplHelper6IN3com3sun4star8document7XFilterENS3_4lang12XServiceInfoENS4_9XExporterENS6_15XInitializationENS3_9container6XNamedENS6_10XUnoTunnelEE14queryInterfaceERKNS3_3uno4TypeE
>  
> (aka "cppu::WeakImplHelper6<com::sun::star::document::XFilter, 
> com::sun::star::lang::XServiceInfo, com::sun::star::document::XExporter, 
> com::sun::star::lang::XInitialization, 
> com::sun::star::container::XNamed, 
> com::sun::star::lang::XUnoTunnel>::queryInterface(com::sun::star::uno::Type 
> const&)") as "t" (nm: non-external text section symbol), causing the 
> linking of liblnglo.dylib (module linguistic) to fail with "Undefined 
> symbols for architecture i386: 
> 'cppu::WeakImplHelper6<com::sun::star::document::XFilter, 
> com::sun::star::lang::XServiceInfo, com::sun::star::document::XExporter, 
> com::sun::star::lang::XInitialization, 
> com::sun::star::container::XNamed, 
> com::sun::star::lang::XUnoTunnel>::queryInterface(com::sun::star::uno::Type 
> const&)', referenced from: vtable for ConvDicXMLExport in convdicxml.o" etc.
>
> With a Clang 3.1 build on Linux, on the other hand, that queryInterface 
> symbol is exported from libxolo.so as "W" (nm: external weak symbol), so 
> liblnglo.so can link against it.

problem is here in linguistic:

 class ConvDicXMLExport : public SvXMLExport

aha... hmm... so this is a problem for template base classes, and we
have a lot of those WeakImplHelperN base classes.

it appears that at least GCC supports a weak attribute; perhaps somebody
could try out what happens with clang when it is added to the definition
of SAL_DLLPUBLIC_TEMPLATE.

diff --git a/sal/inc/sal/types.h b/sal/inc/sal/types.h
index 3db8cf4..28a908d 100644
--- a/sal/inc/sal/types.h
+++ b/sal/inc/sal/types.h
@@ -273,7 +273,7 @@ typedef void *                   sal_Handle;
 #     define SAL_DLLPUBLIC_EXPORT  __attribute__ ((visibility("default")))
 #     define SAL_DLLPUBLIC_IMPORT  __attribute__ ((visibility("default")))
 #     define SAL_DLLPRIVATE        __attribute__ ((visibility("hidden")))
-#     define SAL_DLLPUBLIC_TEMPLATE __attribute__ ((visibility("default")))
+#     define SAL_DLLPUBLIC_TEMPLATE __attribute__
((visibility("default"),weak))
 #   else
 #     define SAL_DLLPUBLIC_EXPORT
 #     define SAL_DLLPUBLIC_IMPORT