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)?
--
Brian D. Ripley, ripley at stats.ox.ac.uk
Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/
University of Oxford, Tel: +44 1865 272861 (self)
1 South Parks Road, +44 1865 272866 (PA)
Oxford OX1 3TG, UK Fax: +44 1865 272595
>>>>> Prof Brian Ripley writes:> 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)?Along with doing this, can we perhaps change JAVA_HOME to something like R_JAVA_HOME? Apparently some applications require JAVA_HOME to be set which in turn overrides the configured values for R ... Best -k
Hi, 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). Cheers, Hin-Tak 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)? >