RPATHS in binaries
kumar.x.srinivasan at oracle.COM
Mon Jul 23 18:00:55 UTC 2012
> 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
run it by the awt team in the awt-dev. This will need extensive testing
>> 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.
More information about the build-dev