On a RHEL6 64bit system using LibreOffice 3.5.0 RC2 (and also confirmed on Fedora and with LibO 3.5.0 RC3) loading the uno python module causes a crash: ---- [dag@moria ~]$ /opt/libreoffice3.5/program/python Python 2.6.1 (r261:67515, Feb 1 2012, 15:06:46) [GCC 4.2.4] on linux2 Type "help", "copyright", "credits" or "license" for more information. > > > import uno terminate called after throwing an instance of 'com::sun::star::registry::InvalidRegistryException' Aborted (core dumped) ---- This issue was discussed and traced in the following mailinglist thread: http://lists.freedesktop.org/archives/libreoffice/2012-February/025166.html A workaround is to remove 2 files: ---- rm /opt/libreoffice3.5/ure/lib/libgcc_s.so.1 rm /opt/libreoffice3.5/ure/lib/libstdc++.so.6 ----
Since it seems highly unlikely this will be fixed before the 3.5.0 release, I added this bug to the "Most annoying bugs" (Bug 37361) list, as well as to the LibO 3.5.0 release notes.
It helps to use --with-system-stdlibs configure options. It seems to be too late and too dangerous to do this for 3.5.0. We might first do it in libreoffice-3-5 branch, ask people for testing daily builds and keep it for 3.5.1 when nobody complains. Let's discuss this on TSC call this week, first.
To clarify: The problem (abort of ".../python -c 'import uno'") should only happen with the LibO packages as available from <http://www.libreoffice.org/download/>. It should not happen with installation sets specificially built for those platforms. <http://cgit.freedesktop.org/libreoffice/core/commit/?id=0b1be1ce0e0ac7b34c4b73d53f4bf32ec5df7290> "Reintroduce pyuno.so wrapper around libpyuno.so" (on master towards LO 3.6) should fix the problem. It re-introduces some dirty platform-specifc makefile code; once it is known to work fine across the various platforms on LO master I will take care to get it cherry-picked into -3-5. The problem is as follows: <cgit.freedesktop.org/libreoffice/core/commit/?id=a09ce46818fd4d5e08b3af9a478501cd8ef5b4fe> "Port PyUno to support Python 3" erroneously cleaned away the pyuno.so wrapper around libpyuno.so (it turned the former into a symlink to the latter). The wrapper is needed to make sure libpyuno.so (which in turn links against many of the URE libs, incl. cppuhelper) is dlopen'ed RTLD_GLOBAL (while Python apparently dlopen's its modules RTLD_LOCAL). At least with pre 4.5 GCC versions where C++ exception RTTI data is compared for equality by only comparing pointers to strings (instead of the content of the strings), this causes an InvalidRegistryException thrown from boostrap.uno.so (dlopen'ed RTLD_GLOBAL via sal) to erroneously not be caught by cppuhelper (loaded as a consequence of loading libpyuno.so aka pyuno.so as RTLD_LOCAL), as the two libs bind to different instances of the InvalidRegistryException RTTI symbols. The problem of loading libpyuno.so as RTLD_LOCAL gets hidden with recent GCC runtimes that actually compare the content of RTTI strings. However, the packages available from <http://www.libreoffice.org/download/> are built on a rather old baseline system and without --without-system-stdlibs, so they include old versions of libstdc++.so.6 and libgcc_s.so.1 that still compare RTTI pointers only (and the programs in the LibO installation then use those versions, instead of the ones provided by the system). Reportedly, the GCC behavior changed with GCC 4.5 (and already with GCC 4.4.1-2 for RHEL/Fedora). That is, only LibO installations that use older libstdc++.so.6/libgcc_s.so.1 than that (either from the system or included in the LibO installation) are affected.
Backported fix to libreoffice-3-5 (towards LO 3.5.1) as <http://cgit.freedesktop.org/libreoffice/core/commit/?h=libreoffice-3-5&id=51967dab002323b62f4f8f635052ab12ceb2b2ad> "Reintroduce pyuno.so wrapper around libpyuno.so."
Seems to be fixed in the LibO 3.5.1 RC1 release. Although the RPM packages do have a new problem related to libstdc++.so.6 :-/ https://bugs.freedesktop.org/show_bug.cgi?id=46658