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