[Libreoffice] feature/gbuild_cppuhelper

Stephan Bergmann sbergman at redhat.com
Fri Dec 23 10:22:34 PST 2011

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 
"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, 
"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.


More information about the LibreOffice mailing list