Re: [Rd] Perils of R_LIBRARY_PATH
Prof Brian Ripley wrote: On Sat, 16 Feb 2008, Hin-Tak Leung wrote: Hi, Just for interest, may I ask which platform are you referring to? You are on a commercial unix platform such as solaris, right? amd64 Linux -- a bit of tracing shows that to be from a jpackage-d version of the Sun SDK. So my guess is that the packaging picked up the libs (I didn't install that particular JDK). Hmm, maybe you should file a bug to the jpackage people. My 1.4/1.5/1.6 came from http://java.sun.com/ - 1.5 and 1.6 are x86_64, 1.4 is i686, and they don't have any gtk/cairo shared libraries. The sun jdk's from sun don't play nice with the alternative system though (whereas the jpackage does). As a long term strategy , sun jdk 1.7 and gcj came with fedora 8. gcj starts to work quite well, so it might be a good idea to support that too. snipped Solaris 10 has Gtk2 but not cairo (which is relevant as R will have a cairo-based version of X11). Gtk(2?) is an offical optional add-on to Tru64. (mostly just because mozilla needs it, I think...) Hin-Tak __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Perils of R_LIBRARY_PATH
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)?
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Perils of R_LIBRARY_PATH
On Sat, 16 Feb 2008, Hin-Tak Leung wrote:
Hi,
Just for interest, may I ask which platform are you referring to?
You are on a commercial unix platform such as solaris, right?
amd64 Linux -- a bit of tracing shows that to be from a jpackage-d version
of the Sun SDK. So my guess is that the packaging picked up the libs (I
didn't install that particular JDK).
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).
Solaris 10 has Gtk2 but not cairo (which is relevant as R will have a
cairo-based version of X11).
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)?
--
Brian D. Ripley, [EMAIL PROTECTED]
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, UKFax: +44 1865 272595
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Perils of R_LIBRARY_PATH
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, [EMAIL PROTECTED]
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, UKFax: +44 1865 272595
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Perils of R_LIBRARY_PATH
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
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
