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

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?

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

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

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
> 
> [...]
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
> 

-- 
John Wolfe				[email protected]
The SCO Group Inc., Murray Hill, NJ	908 790 2399

SCO is a leading provider of UNIX-based solutions and mobile services