[Libreoffice] feature/gbuild_cppuhelper

[Stephan Bergmann]

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