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