Re: [Libreoffice] merging libraries: problem with multiple definitions

Hi Matus,

On Wed, 2011-12-28 at 23:30 +0100, Matúš Kukan wrote:
> I was again working on merging libraries from tail_build:

        Cool ! :-)

> avmedia canvastools cppcanvas deploymentmisc drawinglayer editeng
> filterconfig fwe fwi fwk lng package2 sb sfx sofficeapp spl svx
> svxcore uui xo

        Wow - can we really merge all that lot together ? if so - we're really
starting to get somewhere I think :-)

> But there is problem with multiple definitions:
>
> nCreateSlots and nConvertSlots are references in:
> svx/source/form/fmshimp.o
> framework/source/uielement/controlmenucontroller.o

        So - I think here we just add a 'static' keyword in front of those
(clearly module local) variables.

> aSfxUInt32Item_Impl aSfxBoolItem_Impl aSfxVoidItem_Impl
> aSfxUInt16Item_Impl aSfxStringItem_Impl are referenced in:
> svx/source/form/typemap.o
> sfx2/source/appl/appbas.o

        Gosh - that is more unpleasant :-) I guess we prolly need some magic
inside the svidl .sdi compiler (urgh) and svx/sdi/svxslots.hxx to ensure
that we don't emit anything except externs for:

extern SfxType3 aSvxEscapementItem_Impl;
#ifdef SFX_TYPEMAP
SfxType3 aSvxEscapementItem_Impl = 

        with an #ifdef SVX_TYPEMAP or something there ? When we had a similar
problem in Bonobo land (years ago) we did something like:

#ifndef __Bonobo_COMPILATION
#ifdef __ORBIT_IDL__
%{
#pragma include_defs bonobo/Bonobo.h
%}
#pragma inhibit push
#endif
#endif
...
#ifndef __Bonobo_COMPILATION
#ifdef __ORBIT_IDL__
#pragma inhibit pop
#endif
#endif

        Which then causes plenty of grief in various ways from different
pre-processors: the idea being that this would get through and we could
adapt the #include of that specific IDL file into either a #include<> or
a set of IDL decls depending who compiled it.

> My guess is they are from svxslots.hxx and sfxslots.hxx which are
> somehow created from s.xslots.sdi ?
> What can we do about this ?

        Bit of an annoyance really :-) Quite possibly:

idl/source/objects/types.cxx-
idl/source/objects/types.cxx-    // write the implementation part
idl/source/objects/types.cxx:    rOutStm << "#ifdef SFX_TYPEMAP" << endl
idl/source/objects/types.cxx-            << aTypeName.GetBuffer() <<
aVarName.GetBuffer()
idl/source/objects/types.cxx-            << " = " << endl;

        Could be adapted to use a name based on the mangled name of the SDI
that is included; so:

#ifdef XOITEMS_SDI_TYPEMAP
...
#ifdef SVXITEMS_SDI_TYPEMAP
...
#ifdef FMSLOTS_SDI_TYPEMAP
...

        And then we could choose in either of the files you mention - which of
these we really want to generate.

        That is (of course) assuming we can get the path name into the IDL
compiler's types.cxx ;-) prolly it is hanging around somewhere.

        Does that make some sort of sense ? Really excited to have you working
on this - there should be a lot of scope for improvement from graunching
all of that together and LTO'ing it :-)

        All the best,

                Michael.

-- 
michael.meeks@suse.com  <><, Pseudo Engineer, itinerant idiot