[Libreoffice] build failure loading pythonloader.uno.so

Caolán McNamara caolanm at redhat.com
Sun Oct 24 04:56:39 PDT 2010

On Sun, 2010-10-24 at 01:26 +0200, Thomas Klausner wrote:
> I used "build" with the variable set for my original error and got:
> ..../build/libreoffice- Error in sourced command file:
> Function "__cxa_throw" not defined.

This sucks, looks like catch throw and catch catch don't work on NetBSD.
Or maybe its too old a gdb or something. Maybe add a "break main" and
reorganize the gdb script in the hope that it needs libstdc++ to be
loaded before it'll work. i.e. something like the (untested) attached.

> Perhaps some introductory questions:

> What is this registering step doing?

The registering step should be effectively dlopening the modules that it
wants to register, running the component_writeInfo function and friends
in order to record into a registry file which .sos implement/support
what named services. So manual debugging like adding some printf around
the dlopen/dlsym calls in sal can help find what is the last .so to be
dlopened, and adding/debugging the component_writeInfo etc calls in
that .so can see if they're getting called at all, and sort of narrow
down where things are going wrong.

Later on a runtime the various things like ...
mxSMgr->createInstanceWithContext("com.sun.star.script.Invocation") can
do the right thing, and dlopen the lib that
com.sun.star.script.Invocation is implemented in and call the matching
component_getFactory for that service

> What parts of the tree affect this or could cause this?

cppu, cppuhelper, stoc and bridges are generally involved.

-------------- next part --------------
set pagination off
break main
catch throw
catch catch
echo log will be saved as gdbtrace.log, this will take some time, patience...\n
set logging redirect on
set logging file gdbtrace.log
set logging on
set logging overwrite on
set logging off
echo log is saved as gdbtrace.log\n

More information about the LibreOffice mailing list