Re: Porting to SCO OpenServer 6.0.0 - soffice will not load

John Wolfe wrote:
> Thank you very much.  The clearly is the problem.
> 
> Our present build has these functions exported as weak symbols from 
> numerous shared objects.  I had hastily (and incorrectly) jumped
> to the conclusion that the .map files were controlling function
> ordering within a library.  We had intended to use the USLC
> "fur" tool to specify optimal function ordering or code block
> re-ordering within a function once profiling information was
> available.
> 
> Obviously we now need to revist all 500_ *.map files.
> 
> Are all getCppuType() and cppu_detail_getUnoType() functions
> to be local to each shared object?

Yes.  The two ways of generating these functions with cppumaker break 
the One Definition Rule, so these functions' scope has to be treated 
very carefully (and, all in all, the design is rather broken here).

> What is the guidelines for when a "global" version of the functions
> can be used - presumably the "light" versions after bootstrap?

After bootstrap, it would be harmless for either version to be used 
anywhere.

> Or, is there a specific list of shared objects which must use
> a local "comprehensive" version of the functions?

Only indirectly, grep for BOOTSTRAP_SERVICE in makefiles.

-Stephan

> Thanks again,
> 
> -- John
> 
> Stephan Bergmann wrote:
>> John Wolfe wrote:
>> [...]
>>
>>> Error: File /u/oo-jlw/build/cppuhelper/source/implbase_ex.cxx, Line 252:
>>>  cannot get type description for type
>>>  "com.sun.star.lang.XMultiServiceFactory"!
>>>
>>> Conceivably, this could be expected on initial startup or even at all 
>>> startups ???
>>>
>>> Or, is this an indication that some static initialization has
>>> not been accomplished or not done correctly?
>>>
>>> The types.rdb is not read (mmap'ed) in until later.
>>
>>
>> Information about UNO types (functions getCppuType and, lately added, 
>> cppu_detail_getUnoType) can be generated in two ways by cppumaker: 
>> either "comprehensive," including all the necessary data in the 
>> function body, or "light," just pointing to the information in 
>> types.rdb.  Some shared libraries that are used during soffice 
>> bootstrap use the comprehensive way (as types.rdb is not yet mmapped, 
>> as you observed), while all other shared libraries use the light way.
>>
>> Now, I suspect that you have trouble with symbol exports, that 
>> multiple shared libraries (or probably the soffice.bin executable as 
>> well) export say the XMultiServiceFactory getCppuType function (some 
>> the comprehensive, some the light version), and some bootstrap library 
>> that exports the comprehensive version nevertheless uses the light 
>> version exported from somewhere else.  The MacIntel port had a similar 
>> problem.
>>
>> -Stephan
>>
>> [...]