Aditya Pandey wrote:
Stephan Bergmann <stephan.bergmann <at> sun.com> writes:
The Linux x86 OOo 1.9.x versions built by Sun contain a problematic
libgcc_s.so.1 which causes the problem you describe: If some code is
compiled with a GCC other than the exact version used inside Sun and
then run in an environment where the problematic libgcc_s.so.1 is used,
chances are high that exception handling within that code does not work.
Thanks for responding on this. I am building an Addon that I want to work for
OO 2.0.
The workaround is to use the libgcc_s.so.1 that comes with your GCC,
either by replacing the file in the OOo program directory, or by using
LD_PRELOAD.
I tried the approach of replacing OO's libgcc_s.so.1 by my Fedora
Core 3's and it works :). Thanks for the work around.
IMHO: I (or any SDK developer) should be not replacing/preloading
libgcc_s. Better way might be using same settings as used in
build environment. Is there any public place, where the exact
build environment setup followed in sun is documented --
like usage of gcc.3.4.1 on a particular distribution.
Not that I know of. The crucial point here is that Sun uses a GCC that
was built on a glibc 2.2.0 system; if you too used a GCC built on a
glibc 2.2.0 system, your addon should probably work.
I Sun-internally raised the issue of getting the libgcc_s.so.1 issue
fixed for some future Sun-built OOo version; one thing involved is the
system requirements for (Sun-built) OOo, which are still glibc 2.2.0 for
OOo 2.0 (see <http://www.openoffice.org/product2/reqts.html>).
By the way, the URE comes with a fixed libgcc_s.so.1 (and I currently
cannot remember why we do not use the fixed libgcc_s.so.1 for OOo, too,
but I will try to track that down again).
I did not understand it. OOo comes with libgcc_s.so.1.1.
URE (the UNO Runtime Environment) is a standalone UNO independent of
soffice. It is an individual product, like OOo itself or the SDK, and
can be downloaded from the well-known FTP servers.
That OOo includes a file named libgcc_s.so.1.1 is the result of an
unfortunate naming scheme: To allow for easier product updates using
the RPM mechanism, on Linux most files of an OOo installation are
actually two files, namely XXX.1 and a symbolic link XXX that points to
XXX.1. For libgcc_s.so.1 that means that the original libgcc_s.so.1 is
renamed libgcc_s.so.1.1 and there is an additional symbolic link named
libgcc_s.so.1 that points to libgcc_s.so.1.1.
-Stephan
Aditya
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
