Problem loading GCC 4.0 libraries into Java app

[Zoltan Foley-Fisher]

The root of this issue: in the JRex makefile there is a build  
variable SHARED_LIBRARY_LIBS which links mozilla object files  
directly into the JRex dylib.. but the JRex code we have also loads  
mozilla libraries dynamically, duplicating some symbols.

Removing the SHARED_LIBRARY_LIBS variable solves the issues.

Somehow we were getting away lightly when using GCC 3.3..

Zoltan



On 28 Jun 2007, at 13:59, Zoltan Foley-Fisher wrote:

> Hello there,
>
> We are having an issue with compilation differences between GCC 3.3  
> and 4.0, OS 10.4.10, on PowerPC using 10.3.9 SDK, on Intel using  
> 10.4u SDK.
>
> We are working with the JRex library to embed Gecko framework in a  
> Universal Java application. When we compile using GCC 3.3, the  
> appropriate dynamic libraries are created without problem and  
> packaged into a Java application bundle, which launches correctly.
>
> But when we compile the same code with GCC 4.0, the dynamic  
> libraries are created, but fail to load into our Java application  
> correctly. We see some strange behaviours when using GDB, that  
> occur every time the program is run, and only in very specific  
> places in the large codebase:
>
>
> On PPC, a C++ function is called
>
> nsIXPConnect *xpc = nsContentUtils::XPConnect();
>
> but returns null. nsContentUtils::XPConnect is defined as:
>
> static nsIXPConnect *XPConnect()
>   {
>     return sXPConnect;
>   }
>
>  When we follow the call with GDB we notice that there are two  
> sXPConnect symbols...
>
>
>
>
> On Intel, another C++ function is called:
>
> nsresult rv = CallGetService(NS_SCRIPTSECURITYMANAGER_CONTRACTID,  
> &sSecurityManager);
>
> but the call results in sSecurityManager null. We follow the call  
> with GDB and see correct values and code flow until this function  
> return, where it mysteriously "drops" the value to be assigned to  
> sSecurityManager.
>
> Even more mysteriously, if we move the program counter back with  
> GDB and repeat the function a second time, it returns the value for  
> sSecurityManager correctly!
>
>
>
>
> Have any of you guys encountered such behaviour before?
>
> Thanks for any help,
> Zoltan Foley-Fisher
>
> Atimi Software Inc.