I am assisting with a port of OpenOffice 2.0.3
(buildid=680m7(Build:9044)for SCO's OpenServer 6.0.0 UNIX platform:
- built with the SCO native DevSys - C and C++
- Xorg X11 R6.9.0 X server
- Gimp Toolkit 2.8.x
- STLport - version 4.6
The intent is to sync with the latest stable release when we get
it working.
We have completed the cpp2uno bridge port; the tests pass and
the registration of the embedded Java completes
In fact, in addition to the tests and uses of the OO UDK in the build,
I have run the "Available tests for the UDK modules" prepared by
Stephan Bergmann that I had found on the OpenOffice web-site (last
updated 1/31/2006).
The Solaris packaging (pkgadd) is very close to the SVR4 packaging
tools available on OSR6, so we can essentially use that for test
purposes.
After installation of the packages (or testing from the build
solver tree), the soffice-bin fails to complete startup.
We have enabled debugging (OSL_DEBUG_LEVEL =2) and get the messages:
The application cannot be started.
The component manager is not available.
Truss of the soffice script and children shows nothing obvious.
Comparison with OpenOffice 2.0.3 for Solaris-Intel is similar
- sizes and contents of *rc and *.rdb files in ./program
are similar.
- Solaris truss of soffice follows the same sequence of
events allowing for OS differences.
Starting the soffice script in the debugger shows the
following scenario of events:
- reads in "sofficerc"
- reads in "unorc"
- when trying to create an OServiceManager_Listner(), it throws
the 1st exception.in cppu::__queryDeepNoXinrerface() looking for
pDemandTDR = "com.sun.star.uno.XWeak" type
with "class_date * cd" containing the list:
XMultiServiceFactory
XMultiComponentFactory
XServiceInfo
XInitialization
XUnoTunnel
XSet
XContextEnumerationAccess
XTypeProvider
The exception is stating that type info is not available for
XMultiServiceFactory.
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.
The scenario continues:
- reads "bootstraprc"
- reads "types.rdb"
- reads "services.rdb"
- ultimately throws 2nd exception in cppu::__queryDeepNoXinrerface()
> looking for
"com.sun.star.lang.XComponent"
and the list:
XServiceInfo
XHeirarchicalNameAccess
XTypeDescriptionEnumerationAccess
XInitialization
XTypeProvider
AT this point the "component manager is not available" message
is emitted
Obviously something is not quite correct and I would greatly
appreciate any suggestions or pointers in the right direction.
Thanks in advance.
--
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
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
