[Libreoffice] SW_DLLPUBLIC limitations ...

[Michael Meeks]

Hi guys,

	Soo ... Cedric just had an interesting bug:

On Tue, 2010-10-26 at 18:22 +0200, Cédric Bosdonnat wrote:
> Attached is a diff adding the SW_DLLPUBLIC to the ICheckboxFieldmark
> (and friends). To test the problem, open the p11.doc file.
> 
> sw/source/core/doc/docbm.cxx, line 448 we still have a
> ICheckboxFieldmark.
> sw/source/filter/ww8/wrtww8.cxx, line 3520, the dynamic_cast fails.

	The ICheckboxFieldmark class is an abstract class with no constructor,
as such its type information is likely to be compiled into any
translation unit that uses it.

	Unfortunately - we need to use that typeinfo in a dynamic cast inside
the libmsword split library.

	The consequence of that is that we need to annotate all versions of
that typeinfo to be public (ie. not hidden) such that the run-time
linker (if not compile time) linker will be able to detect and elide
these so they resolve to the same value and the dynamic_cast works.

	Unfortunately SW_DLLPUBLIC cannot do this: since libmsword is a
separate shared library, and it results in a .hidden symbol outside of
the library.

	Hence the suggestion to use SAL_DLLPUBLIC_EXPORT as an annotation for
these classes, which may (un-tested) work on Linux[1]. The question (for
Tor) is - if we have a __declspec(dllexport) on two identical symbols in
two shared libraries that link to each other: will we get some vile
linking conflict ? [ or not ] ;-)

	Thanks,

		Michael.

[1] - though interestingly we also have a map file for libmsword - which
is perhaps also unhelpful here: should we ?
-- 
 michael.meeks at novell.com  <><, Pseudo Engineer, itinerant idiot