Sun JRE 1.5 and libXt

Suma Byrappa suma_byrappa at yahoo.co.in
Sun Sep 24 01:27:44 PDT 2006


Hello,
   
  The 1.5 version of both Sun and the IBM JREs use their own Xt code, where as upto 1.4* versions both the JREs depended libXt.so available on the system.
   
  Due to this, my software is running into an issue. The product I work on, calls some methods from libXt.so. 
   
  Earlier with 1.4 versions of JRE, since libawt.so of JREs depended on libXt.so, there was only one copy of the Xt code in the process (i.e, at run-time), and everything worked fine. Now, with 1.5 version of JREs, libawt.so has it's own Xt code which results in two copies of the Xt code at run-time - one copy is JRE's and the other is from libXt.so my software depends on. In addition to this, both the JREs have limited the scope of Xt symbols defined in them (i.e, in libawt.so) to be local (i.e, accessible only within libawt.so), which means that these symbols are not accessible from other modules in the running process.
   
  As Java comes ahead of my code when the application is run, the libawt.so
  's copies of certain Xt symbols like perDisplayList etc get intialized to proper value (which means the libXt.so's copies of the same remains uninitialzed). As libawt.so has made its Xt symbols inaccessible to outside code, the Xt symbols/code in my software gets resolved to the libXt.so's uninitilaized copies and hence crashes. 
   
  IBM JRE provides backward compatibilty through the use of Java option 
  -Dawt.toolkit=sun.awt.motif.MToolkit
  When this option is specified, IBM Jre switches to the previous implementation where it uses libXt.so instead of its own Xt code. Where as that doesn't happen with Sun JRE. Even when this option set, libawt uses statically linked Xt code and it doesn't expose the Xt symbols to other modules resulting in the above problem.
   
  Has any one on this list are seeing any problems with this change in JRE 1.5? Shouldn't Sun provide backward compatibilty?
   
  Changing my application to depend on JRE or not use libXt.so is not a feasible option, as
  1. We have lot of Xt code in our software.
  2. The same code in my application has to deal with other situations where Java is not at all used.
  3. We need to intercept certain Xt methods, so that we get the control first, do some processing, and then call the real Xt routines.
   
  Any suggestions/thoughts are highly appreciated.
   
  Thanks,
  Suma.

 				
---------------------------------
 Find out what India is talking about on  - Yahoo! Answers India 
 Send FREE SMS to your friend's mobile from Yahoo! Messenger Version 8. Get it NOW
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.x.org/archives/xorg/attachments/20060924/3a1b1498/attachment.html>


More information about the xorg mailing list