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