Also, it only seems to happen when the symbol names are component_canUnload and component_getImplementationEnvironment. Is this really a problem? If not, why would the trace output report it as an error? Why would the code check for these symbols in ld.so.1? Isn't that the linker library?
-----Original Message----- From: Steele, Raymond Sent: Thursday, April 17, 2014 3:58 PM To: 'a...@openoffice.apache.org'; 'dev@openoffice.apache.org' Cc: Meffe, David K; Marks, Jeffrie Subject: RE: EXTERNAL: Re: Extension Manager Add Crashes 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 ld.so.1: 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? Raymond -----Original Message----- From: Steele, Raymond Sent: Tuesday, April 15, 2014 12:28 PM To: a...@openoffice.apache.org; dev@openoffice.apache.org 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 ld.so.1: 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 [mailto:h...@apache.org] Sent: Tuesday, April 15, 2014 7:14 AM To: dev@openoffice.apache.org Cc: a...@openoffice.apache.org 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. [1] https://wiki.openoffice.org/wiki/Uno/Article/Understanding_Uno [2] https://wiki.openoffice.org/wiki/Uno/FAQ [3] http://www.openoffice.org/udk/cpp/man/cpp_bridges.html [4] https://wiki.openoffice.org/w/images/5/5e/DevelopersGuide_OOo3.1.0_05AdvancedUNO.odt 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. Herbert --------------------------------------------------------------------- To unsubscribe, e-mail: api-unsubscr...@openoffice.apache.org For additional commands, e-mail: api-h...@openoffice.apache.org
