On 02/03/2012 06:43 PM, Stephan Bergmann wrote:
On 02/03/2012 04:46 PM, Dag Wieers wrote:
[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)
I can reproduce this with
LibO_3.5.0rc2_Linux_x86-64_install-rpm_en-US.tar.gz from
<http://www.libreoffice.org/download/pre-releases/>. The problem is that
readRdbFile (cppuhelper/soruce/bootstrap.cxx) in
/opt/libreoffice3.5/ure/lib/libuno_cppuhelpergcc3.so.3 calls
SimpleRegistry::open (stoc/source/simpleregistry/simpleregistry.cxx) in
/opt/libreoffice3.5/ure/lib/bootstrap.uno.so (with
rURL="file:///etc/opt/ure/types.rdb"), which throws an instance of
css.registry.InvalidRegistryException (correctly so, as rURL does not
exist), but the code in libuno_cppuhelpergcc3.so.3 fails to catch that
exception with its
catch (css::registry::InvalidRegistryException & e) {
code block. Very suspicious, esp. given that both
libuno_cppuhelpergcc3.so.3 and bootstrap.uno.so export the _ZTI/_ZTS
symbols for InvalidRegistryException (and new GCC versions no longer
compare on the brittle RTTI pointers, but on string equality, anyway).
I have currently no idea what's broken there.
The secret is that the LO installation sets available from
<http://www.libreoffice.org/download> are built with implicit
--without-system-stdlibs, so they bring along ure/lib/libgcc_s.so.1 and
ure/lib/libstdc++.so.6 (which the programs in the LO installation, like
program/soffice.bin and program/python.bin, pick up at runtime).
For reasons that still escape me, this causes exception-handling trouble
for LO 3.5 program/python (which happens to set LD_LIBRARY_PATH, maybe
that makes a difference), but apparently not for LO 3.5 program/soffice,
nor reportedly for LO 3.4 program/python (as reported by Dag).
Removing /opt/libreoffice3.5/ure/lib/libgcc_s.so.1 and
/opt/libreoffice3.5/ure/lib/libstdc++.so.6 made the problem go away for
me on Fedora 16 x86_64.
Petr, the best approach might be to build the "official" Linux LO
installation sets with explicit --with-system-stdlibs, so that the
installation sets do not bring along their own libgcc_s.so.1 and
libstdc++.so.6. If the installation sets are built on a sufficiently
old baseline system, it should be a pretty safe bet that each box on
which they are installed bring along sufficiently new versions of those
libs as part of the system.
Apart from that, Dag, the only safe solution, in principle, is to use a
version of LO that is specificially built for the machine it is run on
(i.e., use a LO installation provided by the respective distro).
Stephan
_______________________________________________
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
