OOo fails at startup on PPC. This has happened since about 1.1.87-1 IIRC, which had other problems (no suitable windowing system found). $ oowriter terminate called after throwing an instance of 'com::sun::star::uno::RuntimeException' /usr/lib/openoffice.org1.9.89/program/soffice: line 237: 5082 Aborted "$sd_prog/$sd_binary" "$@" Breakpoint 2, 0x0e8482cc in std::terminate () from /usr/lib/libstdc++.so.6 (gdb) bt #0 0x0e8482cc in std::terminate () from /usr/lib/libstdc++.so.6 #1 0x0e8484c4 in __cxa_throw () from /usr/lib/libstdc++.so.6 #2 0x0f0dd0c8 in cppu::WeakAggComponentImplHelper_getTypes () from /usr/lib/openoffice.org1.9.89/program/libuno_cppuhelpergcc3.so.3 #3 0x0f0dd3f8 in cppu::WeakComponentImplHelper_query () from /usr/lib/openoffice.org1.9.89/program/libuno_cppuhelpergcc3.so.3 #4 0x0d7afa94 in cppu::WeakComponentImplHelper4<com::sun::star::lang::XServiceInfo, com::sun::star::container::XHierarchicalNameAccess, com::sun::star::reflection::XTypeDescriptionEnumerationAccess, com::sun::star::lang::XInitialization>::queryInterface () from /usr/lib/openoffice.org1.9.89/program/regtypeprov.uno.so #5 0x0d930cbc in stoc_tdmgr::ManagerImpl::insert () from /usr/lib/openoffice.org1.9.89/program/typemgr.uno.so #6 0x0f0d3840 in cppu::bootstrapInitialContext () from /usr/lib/openoffice.org1.9.89/program/libuno_cppuhelpergcc3.so.3 #7 0x0f0d80b0 in cppu::get_unorc () from /usr/lib/openoffice.org1.9.89/program/libuno_cppuhelpergcc3.so.3 #8 0x0f0d88a8 in cppu::defaultBootstrap_InitialComponentContext () from /usr/lib/openoffice.org1.9.89/program/libuno_cppuhelpergcc3.so.3 #9 0x100337b8 in desktop::CommandLineArgs::ParseCommandLine_Impl () #10 0x10033cc8 in desktop::CommandLineArgs::CommandLineArgs () #11 0x1001afc8 in desktop::Desktop::GetCommandLineArgs () #12 0x1002e9b0 in desktop::Desktop::CreateApplicationServiceManager () #13 0x1001b44c in desktop::Desktop::Init () ---Type <return> to continue, or q <return> to quit--- #14 0x0fd078cc in InitVCL () from /usr/lib/openoffice.org1.9.89/program/libvcl680lp.so #15 0x0fd07fc8 in SVMain () from /usr/lib/openoffice.org1.9.89/program/libvcl680lp.so #16 0x1001a89c in sal_main () #17 0x1001a930 in main ()
The openoffice.org-debuginfo package is tiny. I assume it isn't functional so didn't bother to install it. Am rebuilding for myself to get debugging info.
This is probably a manifestation of bug #151955, and even if it isn't there's little point in investigating until #151955 is fixed.
Ack!, that would do it and totally destroy all the uno->c++ bridging.
1.9.89-4 rebuilt with gcc 4.0.0-40 in fc4-HEAD. Does it work under ppc ?
No. I see precisely the same failure mode.
The exception seems to be raised from __queryDeepNoXInterface() in cppuhelper/source/implbase_ex.cxx Adding extra debugging shows: cannot get type description for type "com.sun.star.lang.XServiceInfo"!
This is all deep in the arch/compiler specific uno bridging stuff walking vtables I think. Seeing as OOo *did* work under ppc, something has changed. caolanm->jakub: I'm bewildered, any ideas ?
If I understood aph correctly yesterday, the other thing that changed in this timeframe is that we now compile everything to native code _during_ the build process, rather than using gij throughout. Is it feasible to revert that change to see if it helps?
Nah, if you're referring to the java components the only bits that are compiled with native code in this rpm are the bits used during buildtime.
I was trying to provoke aph into elaborating on precisely what he meant rather than merely making do with my garbled rendition of it :)
To recap: 1.9.85-1 works. 1.9.87-1 fails with a different problem (no suitable windowing system found). 1.9.87-2 has this problem. Looking at the dates of gcc and OOo builds, it looks like the compilers used were: 1.9.85-1: gcc 4.0.0-34 1.9.87-1: gcc 4.0.0-35 1.9.87-2: gcc 4.0.0-35
OK, so we need to see the patches applied to OOo between those releases. I'll look at the gcc changes between -34 and -35.
I'll set gcc-4.0.0-40 building 1.9.85-1 too, in case it sheds any light on the matter (and because it's cold in here today so the extra heat will be nice :)
No suitable windowing system sounds like the missing 32bit startup-notification under 64bit platforms and so should not be relevent (fixed in 1.9.89-4) OOo makes extensive use of namespaces under C++ as well as java I doubt that its a change to OOo that has caused this, though it's not impossible.
cvs diff -rSRC680_m85 -rSRC680_m87 solenv/inc/unxlngppc4.mk shows Index: unxlngppc4.mk =================================================================== RCS file: /cvs/tools/solenv/inc/unxlngppc4.mk,v retrieving revision 1.14 retrieving revision 1.15 diff -u -r1.14 -r1.15 --- unxlngppc4.mk 24 Feb 2005 14:43:41 -0000 1.14 +++ unxlngppc4.mk 15 Mar 2005 09:57:17 -0000 1.15 @@ -150,9 +150,14 @@ DYNAMIC = -Wl,-Bdynamic # name of linker -LINK*=gcc +LINK*=$(CXX) +LINKC*=$(CC) + # default linker flags -LINKFLAGS=-Wl,-rpath,\''$$ORIGIN'\' + +LINKFLAGSDEFS*=-Wl,-export-dynamic +LINKFLAGSRUNPATH*=-Wl,-rpath,\''$$ORIGIN'\' +LINKFLAGS= $(LINKFLAGSDEFS) $(LINKFLAGSRUNPATH) # linker flags for linking applications LINKFLAGSAPPGUI= -Wl,-export-dynamic -Wl,--noinhibit-exec where adding -Wl,-export-dynamic to the link flags is a ppc specific change in the relevent timeframe.
Building a version with this patch now to make it match i386 and see if it helps... -LINKFLAGSDEFS*=-Wl,-export-dynamic +LINKFLAGSDEFS*=-Wl,-z,defs LINKFLAGSRUNPATH*=-Wl,-rpath,\''$$ORIGIN'\' -LINKFLAGS= $(LINKFLAGSDEFS) $(LINKFLAGSRUNPATH) +LINKFLAGS=-z combreloc $(LINKFLAGSDEFS) $(LINKFLAGSRUNPATH)
It fails on my shinybook with its puny 1GiB of RAM: cc1plus: out of memory allocating 1643995136 bytes after a total of 94982144 bytes The same file does compile fairly quickly with gcc 3.4 if you just comment out the calls to __builtin_powi{f,l,}.
openoffice.org-core-1.9.89-5 works fine. Thanks.