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

On Fri, 3 Feb 2012, Stephan Bergmann wrote:

> 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).

Right, loading the uno module using /opt/libreoffice3.5/program/python.bin 
works. (Except it fails in other ways that require LD_LIBRARY_PATH, e.g. 
/opt/libreoffice3.5/program/pyuno.so: undefined symbol: PyUnicodeUCS2_GetSize)


> 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.

Would that be possible before the 3.5 release ?


> 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).

I agree, up to the point that I am mostly interested in RHEL5 and RHEL6 
and that would mean...   ... OpenOffice 3.1.1 or 3.2.1 :-/

But in general the official RPM packages work fine, and I think there's a 
benefit in keeping this working (if practical possible).

Thanks for your insights !

PS I am at FOSDEM and missed you twice at the booth. Can I offer a free 
beer for your help ? :)
--
-- dag wieers, dag@wieers.com, http://dag.wieers.com/
-- dagit linux solutions, info@dagit.net, http://dagit.net/

[Any errors in spelling, tact or fact are transmission errors]