[ESS] SOLVED - Re: ESS and LD_LIBRARY_PATH

[Erik Iverson]

Thanks for your suggestion Marc.  Unfortunately, I'm not root on my 
machine at work!  I bet your suggestion would have worked though.

I thought my problem might be that I was setting the LD_LIBRARY_PATH 
variable in .cshrc.  KDE apparently wasn't sourcing that file on login, 
so it was never getting set.  That's why when starting xemacs from 
command line, it worked.  So I spent a while trying to figure out how 
I'd set an environment variable in KDE at login.  I tried .xinitrc and 
.xsession to no avail.

Ultimately, I stumbled across the KDE Faq, and on page 14 of the PDF 
here http://docs.kde.org/stable/en/kdebase/faq/faq.pdf, it says "Some 
systems (notably Red Hat Linux) use .Xclients instead (of .xinitrc or 
.xsession).  So on my system, I looked at .Xclients, which calls 
.Xclients-default.  This is a bash script, and I simply added

LD_LIBRARY_PATH=~/lib
export LD_LIBRARY_PATH

to my .Xclients-default script.  That worked! The environment variable 
was now set correctly in ESS.

Thanks for all the help on the list!  Hopefully this might help someone 
else someday.

Erik





Marc Schwartz wrote:
> On Wed, 2006-10-18 at 15:14 -0500, Erik Iverson wrote:
> 
>>Hello -
>>
>>Apologies if this is something simple; I've tried everything I can think 
>>of!  I am on RHLE 4, R version 2.3.1, ESS 5.3.0.
>>
>>I have downloaded an R package called Cairo (not on CRAN).  The package
>>Cairo needs to have the Cairo library (www.cairographics.org) installed
>>to function.  Because I'm doing this at work, and do not have root 
>>access, I have installed the Cairo graphics library in ~/lib, as is my 
>>standard practice (I'm *not* talking about the R package Cairo here, I'm 
>>talking about the Cairo graphics library).  I then have LD_LIBRARY_PATH 
>>set to ~/lib in my .cshrc file.  I then installed the R Cairo package 
>>with R CMD INSTALL.
>>
>>Now, from my shell in KDE, I can start R and load the Cairo package.
>> > library(Cairo)
>> >
>>This is great!
>>
>>However, I try from ESS 5.3.0 under XEmacs, also using R version 2.3.1
>> > library(Cairo)
>>Error in dyn.load(x, as.logical(local), as.logical(now)) :
>>	unable to load shared library '/u/iverson/R.tools/lib/Cairo/libs/Cairo.so':
>>   libcairo.so.2: cannot open shared object file: No such file or directory
>>Error in library(Cairo) : .First.lib failed for 'Cairo'
>>
>>It can't find libcairo.so.2, which is in ~/lib.
>>
>>I can't figure out why when starting R from my shell, I can load Cairo, 
>>but not when using R under ESS.
>>
>>I check the LD_LIBRARY_PATH environment variable from the R session 
>>started in my shell:
>> > Sys.getenv("LD_LIBRARY_PATH")
>>LD_LIBRARY_PATH
>>"/s/pkg/linux/R/2.2.1/lib/R/lib: ... :/u/iverson/lib"
>>I omit some paths here, but note it has ~/lib.
>>
>>I now check LD_LIBRARY_PATH from the R session in ESS:
>> > Sys.getenv("LD_LIBRARY_PATH")
>> 
>>
>>                                                LD_LIBRARY_PATH
>>"/s/pkg/linux/R/2.2.1/lib/R/lib: ..."
>>This returned the same string as above, *except* for ~/lib!
>>I thought, no problem, I'll just append ~/lib to LD_LIBRARY_PATH using 
>>Sys.putenv() in R under ESS.
>>
>>It looked like it appended ~/lib correctly according to Sys.getenv(), 
>>but library(Cairo) still wouldn't work, same error as above to my 
>>surprise.  Setting LD_LIBRARY_PATH in my .Renviron file didn't change 
>>the error message either.
>>
>>Any thoughts on this?  I was able to get the Cairo package loaded in an 
>>R session started from my Xemacs shell also, so my naive guess is that 
>>this isn't an Xemacs issue.
>>
>>Thanks for any help or suggestions anyone can offer, I've tried all I 
>>can think of!
>>Erik Iverson
> 
> 
> Erik,
> 
> This behavior sounds similar to what I experienced earlier in the year
> on FC4 when using the RODBC package with the Oracle ODBC Linux Driver:
> 
> http://tolstoy.newcastle.edu.au/R/devel/06/03/4447.html
> 
> All had worked well up until some change, which I have yet to identify.
> I can only presume that there was some system update that altered the
> behavior of the user environment. Tracking through the various login
> shell scripts, I could not identify differences in the login shell
> versus the interactive shell relative to environment settings.
> 
> That behavioral change resulted in LD_LIBRARY_PATH being "stepped on" as
> you seem to be experiencing.
> 
> After several go rounds with possible solutions, I finally did the
> following:
> 
> 1. As root (ie. su), edit /etc/ld.so.conf and add the path to the file.
> For example, in my case, it now contains:
> 
> $ cat /etc/ld.so.conf
> include ld.so.conf.d/*.conf
> /usr/lib/oracle/10.2.0.1/client/lib
> 
> 
> 2. Then, also as root, run:
> 
> /sbin/ldconfig
> 
> That will update the LD_LIBRARY_PATH with the change(s) you make in the
> file.
> 
> 
> Once you do that, you should be good to go.
> 
> Note that setting LD_LIBRARY_PATH in this fashion, it will not show up
> in the bash shell:
> 
> $ $LD_LIBRARY_PATH
> $ 
> 
> Nor within R:
> 
> 
>>Sys.getenv("LD_LIBRARY_PATH")
> 
> 
> LD_LIBRARY_PATH
> "/usr/local/lib/R/lib:/usr/local/lib:/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre/lib/i386"
> 
> 
> However, it does work.  :-)
> 
> HTH,
> 
> Marc Schwartz
> 
>