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.me...@novell.com <><, Pseudo Engineer, itinerant idiot _______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice