openoffice-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Steele, Raymond" <>
Subject RE: EXTERNAL: Re: Extension Manager Add Crashes
Date Thu, 17 Apr 2014 22:58:27 GMT
I traced this osl_getAsciiFunctionSymbol issues down to sal/osl/unx/module.c line 154.

Apparently, the function osl_getAsciiDunctionSymbol is calling "dlsym" (fcnAddr = dlsym(Module,
pSymbol)  which attempts to get the address of a symbol in a shared object or executable.
 NULL is returned if address of the symbol's name as a character string cannot be found. 

In the case of "error: osl_getAsciiFunctionSymbol failed with soffice.bin: fatal:
component_getImplementationEnvironmnet: can't find symbol" I received in my trace output,
null is returned.

(from dbx dump)
fcnAddr = (nil)
pSymbol = 0xfdc7710 " component_getImplementationEnvironmnet" 
Module = 0xf80008e0

Also,  I noticed this call to dlsym is wraped in an #ifndef NO_DL_FUNCTIONS, however this
is not defined in my environment. What is the significance of calling dlsym, can't I simple
define NO_DL_FUNCTIONS to prevent this from occurring or will this have a negative impact
on my underlying issue with the bridge?


-----Original Message-----
From: Steele, Raymond 
Sent: Tuesday, April 15, 2014 12:28 PM
Cc: Meffe, David K
Subject: RE: EXTERNAL: Re: Extension Manager Add Crashes

Thanks AGAIN, Herbert. 

Is there any significance to the following trace output:

Trace 23946/1: "error: osl_getAsciiFunctionSympol failed with soffice.bin: fatal:
component_getImplementationEnvironmnet: can't find symbol

 I see this a lot while OpenOffice is launching. It appears to happen right before SAL_CALL
uno_getMapping is called.

-----Original Message-----
From: Herbert Duerr [] 
Sent: Tuesday, April 15, 2014 7:14 AM
Subject: Re: EXTERNAL: Re: Extension Manager Add Crashes

On 14.04.2014 17:59, Steele, Raymond wrote:
> Anyone available that understands the OpenOffice bridges or could point me to the correct
documentation so that I can begin to understand the problem myself? This has been a road block
for me.

The OpenOffice bridges are part of the UNO framework. An overview [1] and FAQ [2] can help
to get started into this topic. Especially see the FAQ's chapter 2.9 ("Why is it so annoying
to write a compiler version dependent C++ bridge?") on the deliberate design decisions that
lead to this unfortunate fragility. There are other applications in the same league as OpenOffice
that use plain implementation languages and thus avoid these extreme platform dependencies.


There is a good chance that the ABI hasn't much changed and that the different compiler versions
produces similar enough code so that one could eventually get along with minor tweaks to the
Sparc Solaris UNO bridge. But finding the right knobs to tweak is a bit tricky. I hope the
references above help to solve this.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message