https://bugs.freedesktop.org/show_bug.cgi?id=61155
Stephan Bergmann <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected] --- Comment #1 from Stephan Bergmann <[email protected]> --- This is already using UNO type information while bootstrapping the type information database (frame 20, createTypeRegistry). Either something is horribly broken and leads to this code path that should normally not be taken; building with --enable-debug and/or --enable-dbgutil (requires a complete rebuild, --enable-dbgutil swiches the output dirs from solenv/*.pro to solenv/* etc.) should reveal that. Or, this should pick up the "comprehensively" generated UNO type information in workdir/*/UnoApiHeadersTarget/udkapi/comprehensive/com/sun/star/.../*.hpp files (which is specificially there to use UNO type information already during bootstrap) but for some reason doesn't. The latter would typically be due to symbol visibility problems, where one library that shall use a "comprehensive" cppu_detail_getCppuType variant erroneously binds against a "normal" one from another library. <http://cgit.freedesktop.org/libreoffice/core/commit/?id=dee53a32a9feba2021782db5762b5a9a034efae4> "Temporary hack around cppu_detail_getCppuType variants violating ODR" should mitigate that problem, but maybe doesn't for you. Depending on linker, LD_DEBUG might help to find out whether libraries like libuno_cppuhelper link to symbols with "cppu_detail_getCppuType" in their names that come from other libraries. -- You are receiving this mail because: You are the assignee for the bug.
_______________________________________________ Libreoffice-bugs mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
