RPATHS in binaries (original) (raw)
Kumar Srinivasan kumar.x.srinivasan at oracle.COM
Mon Jul 23 18:00:55 UTC 2012
- Previous message (by thread): RPATHS in binaries
- Next message (by thread): RFR: 7130909 Add a more general mechanism for customizing the build logic
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Hi Omair,
Hi Kumar,
On 07/23/2012 11:19 AM, Kumar Srinivasan wrote: My suggestion is to see if System.loadLibrary can be used, this will bode well for the modularization effort. Unfortunately, this bug can come up with proprietary third-party code that cant be modified by the users of OpenJDK. Also, requiring applications to modify existing code to work against newer versions of OpenJDK seems like a break in binary compatibility. It might be possible to modify the code in OpenJDK to load libjawt.so always before the application code starts. Is that something we want to do on every JVM start? On the other hand, libjawt.so requires libmawt.so to be loaded too. So if libjawt.so can be loaded, that means libmawt.so has been loaded too. Perhaps we can get by with jus add a System.loadLibrary("jawt") at the point in code that loads libmawt.so.h libmawt.so was added a long time ago allowing us to switch between two versions of Motif libraries for Solaris (1.2 and 2.1 I think). But definitely please run it by the awt team in the awt-dev. This will need extensive testing on Solaris.
Thanks Kumar
If this must be added to RPATH in which case, append this last to ensure we don't break anything. I will keep this in mind. I did want to point out that the RPATH change is what most applications are expecting and so is likely to be the most backwards-compatible fix. Thanks, Omair
- Previous message (by thread): RPATHS in binaries
- Next message (by thread): RFR: 7130909 Add a more general mechanism for customizing the build logic
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]