Re: [Libreoffice] LibO 3.5RC2: terminate called after throwing an instance of 'com::sun::star::registry::InvalidRegistryException'

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