Just to let you know that the feature/gbuild_cppuhelper branch compiled
(up through smoketestoo_native) on unxmacxi --enable-dbgutil now, when
cherry-picked on top of master
<http://cgit.freedesktop.org/libreoffice/core/commit/?id=c9bc4a04064f15906ab94cd6c0b175609f3a2ad2>
"rtl::OString::copy with count too large raises assert."
An additional problem was that cppuhelper depends on C++ headers for
certain UNO types to be generated with cppumaker -C ("comprehensive"),
which leads to inline cppu_detail_getUnoType function definitions being
emitted with bodies differing from those emitted when cppumaker is
called without -C. This violation of ODR used to go unnoticed, due to
cppuhelper reducing its set of exported functions via map files (so that
calls to cppu_detail_getUnoType were statically bound to the correct
versions within the cppuhelper library). Now, however, when cppuhelper
symbols are no longer reduced (at least on Mac OS X and Windows), this
causes cppuhelper to pick wrong definitions of the
cppu_detail_getUnoType functions from other libraries (from cppumaker
invocations without -C, which require an already bootstrapped UNO
runtime, which is not the case when cppuhelper bootstraps UNO, so those
calls fail to work).
As a temporary workaround,
<http://cgit.freedesktop.org/libreoffice/core/commit/?h=feature/gbuild_cppuhelper&id=3c92f54309df6b8b0008993962719e2d9ae7b94d>
"Temporary hack around cppu_detail_getCppuType variants violating ODR."
on the feature/gbuild_cppuhelper branch now causes cppumaker to *always*
emit all the types needed during cppuhelper bootstrap as if -C was
specified. This should be revisited when types.rdb (and the way UNO
type information is represented in the C++ binding) is reviewed -- which
is planned for early next year, anyway.
Stephan
_______________________________________________
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
