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: dev-unsubscribeporting.openoffice.org
> For additional commands, e-mail: dev-helpporting.openoffice.org
> 

-- 
John Wolfe				jlwsco.com
The SCO Group Inc., Murray Hill, NJ	908 790 2399

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

------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribeporting.openoffice.org
For additional commands, e-mail: dev-helpporting.openoffice.org