On 2009/04/20 09:44, LEVAI Daniel wrote: > Hi! > > I'm using today's snapshot, and the openoffice-3.0.1p3 package and a clean > ~/.openoffice.org/ directory. When trying to start it with soffice, I get > this popup: > > [OpenOffice.org 3.0 - Fatal Error] > The application cannot be started. > The user interface language cannot be determined. .. > ... and in the console a lot of warnings about libraries (attached, because > of > very long lines) .. > /usr/local/openoffice.org3/program/soffice.bin:/usr/lib/libstdc++.so.47.0: > /usr/local/lib/libestdc++.so.8.0 : WARNING: > symbol(_ZTISt23__codecvt_abstract_baseIcc11__mbstate_tE) size mismatch, > relink your program ..
OOo 3 must be built with gcc 4 [see footnote 0] and pulls in libestdc++ from the gcc 4 port. textproc/libwpd, textproc/icu4c and devel/gperf all pull in libstdc++ (GCC 3). if you try and mix the two in the same process you have conflicting symbols. - gperf is also used by webkit (GCC 4), libiconv, a2ps (C only). - libwpd and icu4c are also used by OOo 2 (GCC 3 C++), webkit (GCC 4 C++), yaz, tin and dwdiff (C only). -> question / thinking aloud: are the C ABIs also incompatible between GCC 3 and 4, or is it just C++? I'm wondering if it's going to be possible to switch OOo 2 to GCC 4 (or remove it) and then move these libraries over to being built with GCC 4 (on arch which support it), or is that just going to result in problems for the other software? is it silently broken or noisy? (I'll try it if I can work out what patches are needed to get gperf built with GCC4).. > /usr/local/openoffice.org3/program/soffice.bin:/usr/X11R6/lib/modules/dri/r300_dri.so: > undefined symbol '_glapi_Dispatch' > /usr/local/openoffice.org3/program/soffice.bin:/usr/X11R6/lib/modules/dri/r300_dri.so: > undefined symbol '_glapi_Context' I think this may also be related to mixing GCC 3/4, iirc Mesa uses C++. and now, SIGCOFFEE. [0] as an aside for those interested why, it supports C++ constructs that gcc 3 can't handle, sometimes they can be unwrapped a bit so you can spoon-feed them to help out the compiler front-end; it's not super complicated but it is fiddly, few people know how to do it (the one I managed myself was more through luck than anything else, I really don't know C++), and the error messages given by gcc when it doesn't understand how to parse something Do Not Help All That Much ;-) here are examples of the sort of changes that have been made to work around some of these in various ports, you can find more if you dig through "grep . `locate patches/|grep 'patch-.*[ch][px][px]$'`|more". - SKIPSMImagePixelType icurrent(SKIPSMImagePixelType(sa(sx))); + SKIPSMImagePixelType foo = SKIPSMImagePixelType(sa(sx)); + SKIPSMImagePixelType icurrent(foo); - typedef typename SizeToType<sizeof(*typeToSize(t() + u()))>::result Promote; + typedef typename SizeToType<sizeof(*typeToSize(PromoteType::t() + PromoteType::u()))>::result Promote; - ::rtl::OUString aMessage( String( ModuleRes( STR_CTW_UNSUPPORTED_COLUMN_TYPE ) ) ); + ::rtl::OUString aMessage = ::rtl::OUString ( String( ModuleRes( STR_CTW_UNSUPPORTED_COLUMN_TYPE ) ) ); - KFileDialog fdlg(QString(),filters, parent); + QString s; + KFileDialog fdlg(s, filters, parent); - Atom * Molecule::CreateAtom() + OpenBabel::OBAtom * Molecule::CreateAtom() - QDBusInterface( QDBusConnection::sessionBus().baseService(), "/kmplot", "org.kde.kmplot.KmPlot" ).call( QDBus::NoBlock, "stopDrawing" ); + QDBusReply<bool> reply = QDBusInterface( QDBusConnection::sessionBus().baseService(), "/kmplot", "org.kde.kmplot.KmPlot" ).call( QDBus::NoBlock, "stopDrawing" ); - QTextStream( stderr, QIODevice::WriteOnly ) + QTextStream out( stderr, QIODevice::WriteOnly ); + + out
