R help - Aug 2018 - R shared library (/usr/lib64/R/lib/libR.so) not found.

See in-line below.

On 08/25/2018 01:10 AM, Ista Zahn wrote:
> On Thu, Aug 23, 2018 at 6:57 AM Rolf Turner <r.turner at
auckland.ac.nz> wrote:
>>
>>
>> I *think* that this is an R question (and *not* an RStudio question!)
> 
> I think this is actually and Ubuntu question, and probably belongs on
> R-sig-debian.
Well, it's about installing R --- *could* be independent of OS.
>>
>> I have, somewhat against my better judgement, decided to experiment
with
>> using RStudio.
>>
>> I downloaded and install RStudio.  Easy-peasy.  Nice lucid
instructions.
>>
>> Then I tried to start RStudio ("rstudio" from the command
line)
>> and got a pop-up window with the error message:
>>
>>> R shared library (/usr/lib64/R/lib/libR.so) not found. If this
>>> is a custom build of R, was it built with the --enable-R-shlib
option?
>>
>> Oops, no, I guess it wasn't.  So I carefully did a
>>
>>       sudo make uninstall
>>       make clean
>>       make distclean
>>
>> and then did
>>
>>       ./R-3.5.1/configure <various flags>
>>
>> making sure I added the --enable-R-shlib flag.
>>
>> Then I did make and sudo make install.
> 
> IMO if you are compiling and installing software yourself on Linux
> your are Doing It Wrong. Use the package manager, that is what it is
> there for.
I was pretty sure that the foregoing was a complete red herring.  And I 
was right.

I have been told by younger and wiser heads that installing from source 
is The Right Thing to Do.  Moreover I'd always had the impression that 
the version of R provided by the package manager persistently lags one 
or two releases behind the current version.  However, given that the 
suggestion had been made, I decided I'd try it.

The process for installing R using the package manager is far from 
straightforward and few people give clear instructions on this issue.
(Instructions are usually incomplete and full of jargon and acronyms 
that the instructors blithely assume assume that the instructees 
understand.  (They *don't*! In this instance (mirabile dictu!) I managed 
(using Uncle Google) to find very clear and explicit instructions at:

https://www.digitalocean.com/community/tutorials/how-to-install-r-on-ubuntu-18-04-quickstart

I followed these instructions, and everything went swimmingly.  I indeed 
got the current version of R (3.5.1, "Feather Spray").  So my previous
impression was incorrect (given that one carefully follows the rather 
complex installation procedures, at least).

Interestingly (???) the "new" R was installed in /usr/bin and not in 
/usr/local/bin.

I then tried issuing the command:

     rstudio

Exactly the same pop-up error.  No help at all, as I expected.

I then tried

     sudo apt install r-base-dev

thinking that this might be needed to get the libR.so created (in the 
right place).  No joy.

I then tried the symlink strategy that I had previously suggested.  No 
joy there either.

Then finally, in desperation, I copied libR.so from /usr/lib/R/lib to
/usr/lib64/R/lib.  Bingo!!!  I can now start Rstudio!!!

It remains mysterious to me why the symlink procedure did not work, 
whereas making a copy of libR.so *did* work.

However I guess this really doesn't matter.  It's now working.

cheers,

Rolf
> --Ista
> 
> It all seemed to go ...
>> but then I did
>>
>>       rstudio
>>
>> again and got the same popup error.
>>
>> There is indeed *no* libR.so in /usr/lib64/R/lib.
>>
>> There *is* a libR.so in /usr/lib/R/lib, but (weirdly) ls -l reveals
that
>> it dates from the my previous install of R-3.5.1 for which I *did not*
>> configure with --enable-R-shlib.
>>
>> Can anyone explain to me WTF is going on?
>>
>> What should I do?  Just make a symbolic link from
/usr/lib/R/lib/libR.so
>> to /usr/lib64/R/lib/libR.so?
>>
>> It bothers me that /usr/lib/R/lib/libR.so was not "refreshed"
from my
>> most recent install of R.
>>
>> I plead for enlightenment.
>>
>> cheers,
>>
>> Rolf Turner
>>
>> P.S. I'm running Ubuntu 18.04.  And the previous install of R was
done
>> under Ubuntu 18.04.
>>
>> R. T.
-- 
Technical Editor ANZJS
Department of Statistics
University of Auckland
Phone: +64-9-373-7599 ext. 88276

Rolf,

I noticed this thread started by you as well as a few of the excellent
follow-ups. While it conclcuded, allow me a few quick comments:

 - Some of us go through some effort to provide R on Ubuntu (and Debian) in a
   reliable and reproducible manner. And it works and is used by many people.

 - The basic r-base (and r-base-core etc) packages work in the distribution,
   but may be older as the distribution is taken as snapshots in time.  Hence
   the Ubuntu mirror via CRAN. That way you get a choice between eg R 3.4.4
   (not that old) and R 3.5.1. (brand new) in the current Ubuntu 18.04.

 - The (short) instructions at CRAN work: add a repo, install from it.
   Neither they nor the longer (more recent) blog post you found (which says
   the same, with more pictures) suggest to link or move libraries around.

 - We even have "proof" in the sense of fully automated build and use
   systems. Docker is just one example.  Eg this Dockerfile build the r-base
   container available as rocker/r-base (as well as the official r-base)
      https://github.com/rocker-org/rocker/blob/master/r-base/Dockerfile
   and eg this one use it and builds on top to generated an RStudio container
     
https://github.com/rocker-org/rocker/blob/master/rstudio/testing/Dockerfile
   Nowhere in either of these "recipes" are library files moved,
renamed, or
   otherwise altered.

 - Nobody ever suggested for _any_ Linux distribution to mix its files below
   /usr with your own compilation.  There lies madness, and it may be the
   root cause of the behaviour local to your machine.  Don't do it.

 - Please consider asking Debian and Ubuntu related questions on r-sig-debian.  

Regards, Dirk

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | edd at debian.org

G'day Rolf,

On Sat, 25 Aug 2018 11:20:09 +1200
Rolf Turner <r.turner at auckland.ac.nz> wrote:
> I was pretty sure that the foregoing was a complete red herring.  And
> I was right.
I am not sure whether I agree. :)
 
> I have been told by younger and wiser heads that installing from
> source is The Right Thing to Do. 
Younger heads probably have more time on their hands to play around
with installing from source and debugging when things go wrong.  Wiser
heads probably have figured out how they should do so in the first
place. :)

Seriously, years ago I installed quite a bit of software from source,
also to always have the newest version.  And while I was using Debian
unstable I accepted that from time to time an update would leave me
with a broken system and I would have to spend some time to fix it
again.  Nowadays, I rather spend my time on other things and so am
happy to go with most software with whatever version the package
installer of Ubuntu installs.

The one exception is R, but that is for various good reasons:
  * I want to have the 32 bit and 64 bit architecture installed so
    that I can test my packages on both packages.  
  * I would like to keep old versions around, to test my packages on
    them
  * I like to use the R version that is installed in our computer
    lab when preparing teaching material, and the newest version
    otherwise.

If I ever get the feeling that all these points are easily achievable
with the compiled packages (without having to play around with docker,
sandboxes etc), I would stop compiling R from source.
> Moreover I'd always had the impression that the version of R provided
> by the package manager persistently lags one or two releases behind
> the current version.
From the official repositories, yes.  But CRAN provides since longer
than I can remember up-to-date binary packages for the most common
Linux distributions.  AFAIK, Debian and Ubuntu packages are available
thanks to Dirk Eddelbuettel (initially? mainly?) and others.
> The process for installing R using the package manager is far from 
> straightforward and few people give clear instructions on this issue.
1.) Start a web browser
2.) Go to your favourite CRAN server
3.) Select 'Download R for Linux'
4.) Select the directory "ubuntu/" from the page that is served
5.) Select README.html from the page that is served
6.) Follow the instructions
> (Instructions are usually incomplete and full of jargon and acronyms 
> that the instructors blithely assume assume that the instructees 
> understand.  
I am sure (some) of my students have the same complains about my
lecturing....   
> (They *don't*! In this instance (mirabile dictu!) I managed (using
> Uncle Google) 
You were lucky in this case, usually Uncle Google serves me with
somewhat out-dated (if not wrong) information when I run into a
technical problem with linux.....
> to find very clear and explicit instructions at:
> 
>
https://www.digitalocean.com/community/tutorials/how-to-install-r-on-ubuntu-18-04-quickstart
> 
> I followed these instructions, and everything went swimmingly. 
You were lucky that you are not sitting behind a firewall (as I seem to
be, not sure whom I have to thank for that).  For me the first step
(installing the GPG key) fails and some further googling was
necessary.  Though, I was working from the CRAN instructions.
> Interestingly (???) the "new" R was installed in /usr/bin and not
in
> /usr/local/bin.
Of course, it is a system Ubuntu package, so it installs to /usr/bin.
> I then tried issuing the command:
> 
>      rstudio
> 
> Exactly the same pop-up error.  No help at all, as I expected.
O.k., as I got a new machine, I installed (X)ubuntu 18.04 from scratch,
no update from an earlier version.  The R version installed from
r-base-core was R 3.4.4.  In a terminal in which I manipulated my PATH
variable so that /usr/bin is early on, I could start R without problem,
and I could start rstudio without problem.

After following the instructions on CRAN and updating my apt
information, I have now R 3.5.1 installed.  And it starts fine from the
command line as does rstudio.  And rstudio starts now with R 3.5.1.

Both these packages work out of the box.  Thus I wonder whether you
have somehow messed up your system during the attempt to install R from
source.  Or have some environment variables set that provide rstudio
with wrong information....
> Then finally, in desperation, I copied libR.so from /usr/lib/R/lib to
> /usr/lib64/R/lib.  Bingo!!!  I can now start Rstudio!!!
I keep wondering why you have a /usr/lib64.

On my Ubuntu boxes, in /usr I have /lib, /lib32 and /libx32, but no
lib64.  As far as I know, Debian/Ubuntu 64bit implementations always
used /usr/lib for its 64 bit libraries and /usr/lib32 for the 32 bit
versions (unlike other distributions who used /usr/lib64 for the former
and /usr/lib for the latter).

In fact, a 'locate /lib64' on my Ubuntu 18.04 system (less than 2 week
old fresh installation) shows:

/lib64
/lib64/ld-linux-x86-64.so.2
/usr/src/linux-headers-4.15.0-32/arch/sh/lib64
/usr/src/linux-headers-4.15.0-32/arch/sh/lib64/Makefile
/usr/src/linux-headers-4.15.0-33/arch/sh/lib64
/usr/src/linux-headers-4.15.0-33/arch/sh/lib64/Makefile

So there seems to be a /lib64, but no /usr/lib64.  How did you get
this?  And why does rstudio think it has to look into that directory?
> It remains mysterious to me why the symlink procedure did not work, 
> whereas making a copy of libR.so *did* work.
Agreed, that is somebody a mystery.
> However I guess this really doesn't matter.  It's now working.
Until it breaks again. :)

I would advise to start at some point with a clean Ubuntu installation,
and then restrict yourself to /usr/local and /opt when installing
software from source.  

Cheers,

	Berwin

On 08/26/2018 02:59 AM, Berwin A Turlach wrote:
> G'day Rolf,
> 
> On Sat, 25 Aug 2018 11:20:09 +1200
> Rolf Turner <r.turner at auckland.ac.nz> wrote:
> 
>> I was pretty sure that the foregoing was a complete red herring.  And
>> I was right.
> 
> I am not sure whether I agree. :)
Huh?  Black is white and up is down???

I did as advised and it made absolutely no difference.  Ergo  I was right.

<SNIP>
> I keep wondering why you have a /usr/lib64.
<SNIP>
> .... How did you get this? 
I have no idea.  It just seems to be there.  And it seems that rstudio 
thinks that it should be there.
> And why does rstudio think it has to look into that directory?
How would I know?  You would have to ask RStudio, not me.

Anyway, I seem to have (for the time being at least) a working system, 
and I don't feel like wasting any more time on this issue.

cheers,

Rolf

-- 
Technical Editor ANZJS
Department of Statistics
University of Auckland
Phone: +64-9-373-7599 ext. 88276