[Rd] Perils of R_LIBRARY_PATH

Hin-Tak Leung hin-tak.leung at cimr.cam.ac.uk
Sat Feb 16 04:09:33 CET 2008


Just for interest, may I ask which platform are you referring to?
You are on a commercial unix platform such as solaris, right?

Older JDK/JRE on unices uses motif as the the AWT peer implementation.
The motif toolkit libraries are always found on commercial unices, but
for the same reason, not found on linux (and Sun JDK for linux used to
link to motif statically, I think). Recent JDK/JRE uses a Gtk AWT peer
(also the case for gcj). I have Sun JDK 1.4, 1.5, 1.6 and the newly
open-sourced 1.7 (this comes with fedora 8) on linux (as well as gcj),
but none of them have gtk libs bundled... but I can imagine Sun need to
ship gtk libs with jdk for older commercial unices - newer commercial 
unices may or may not have the gtk libs. (some do, I believe).


Prof Brian Ripley wrote:
> The R front end sets (via etc/ldpath) R_LIBRARY_PATH, including 
> R_JAVA_LD_LIBRARY_PATH.  Perhaps the later is too obliging, as I've just 
> be caught by it in a way that took me a while to track down.
> One of my machines has a Sun jdk1.6.0* JDK installed, and as a result
> we have
> ${R_JAVA_LD_LIBRARY_PATH=${JAVA_HOME}/lib/amd64/server:${JAVA_HOME}/lib/amd64:
> ${JAVA_HOME}/../lib/amd64}
> What I was not aware of was that the Sun JDK contains Gtk+ libraries such 
> as cairo and pango, and those were older than the ones whose headers I 
> had compiled against which eventually resulted in a crash.
> It seems to be an issue only for a JDK: perhaps Simon can tweak his 
> incantations to use only the JRE library path (and avoid the 
> '../lib/amd64' above)?

More information about the R-devel mailing list