Perils of R_LIBRARY_PATH

[Prof Brian Ripley]

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,                  [hidden email]
Professor of Applied Statistics,  http://www.stats.ox.ac.uk/~ripley/
University of Oxford,             Tel:  [phone] (self)
1 South Parks Road,                     [phone] (PA)
Oxford OX1 3TG, UK                Fax:  [phone]

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Kurt Hornik]

>>>>> 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

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Hin-Tak Leung-2]

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)?
>

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Prof Brian Ripley]

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,                  [hidden email]
Professor of Applied Statistics,  http://www.stats.ox.ac.uk/~ripley/
University of Oxford,             Tel:  [phone] (self)
1 South Parks Road,                     [phone] (PA)
Oxford OX1 3TG, UK                Fax:  [phone]

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Hin-Tak Leung-2]

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

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel