Updating gcc on Google Compute Engine Debian 9.13 VM to make R packages install properly - r

I am on a VM spun up by Google Compute Engine, running Debian 9.13. I am having problems installing R packages to both R 3.3.3 and R 4.0.1, with non-zero exit status preventing successful install. One of the remedies from other answers here and in RStudio Community is to make sure gcc is updated. So I follow the instructions for Debian 9.13 and do:
sudo apt install build-essential
... which tells me that build-essential is already the newest version (12.3). But when I check the gcc version it shows me a very old version:
User#myvm-1:/usr/local/ $ gcc --version
gcc (Debian 6.3.0-18+deb9u1) 6.3.0 20170516
Copyright (C) 2016 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Because this is on a GCE VM, I am wondering if there is a simpler way to update the compiler -- or if there is a completely different way to help get my R packages to install without the non-zero exit status error. Any insights would be appreciated.

Let's back off a little here. You choose Debian 9.13, or the 13th and final version of "oldstable" (see https://www.debian.org/News/2020/20200718).
If you want newer tools, maybe you should start with Debian 10 aka "stable"? (I happen to be a strong believer in using Debian "testing" which I use for example as the basis of the official "r-base" Rocker container for R, but that is a different story. You could also use Ubuntu LTS which tends to be newer than Debian stable which is very conservative). Now, even if you stay with Debian stable I think you will get gcc-7 or gcc-8.
Next, we need to see the actual compilation errors to help you.
Lastly, know that Debian has a) a fair number of binary packages for R and b) very good "backported" packages of R itself at CRAN in the directory http://cloud.r-project.org/bin/linux/debian/

Related

Upgrade R version 2.15.1 to 3.3 on Debian server (linux-gnu)

I'm in internship and I'm working on a Debian server
for my R's scripts.
However, the version installed on the server is really outdated (2.15.1)
and I think, it might be the reason of some errors I have with my scripts
(which work on my windows PC with R 3.3).
But I am totally a beginner with Linux and I'm stuck.
I know there is a tutorial (https://cran.r-project.org/bin/linux/debian/)
but it's a very specific vocabulary I don't understand completely + my inexperience with Linux servers make it hard to understand exactly what I have to do.
Is it possible to have more explanations on how to install R 3.3 on Debian
server ?
Here are the details from sessionInfo() of the server :
R version 2.15.1 (2012-06-22)
Platform : i486-pc-linux-gnu (32 bit)
I would suggest that you install the '-dev' version of base R
sudo apt-get install r-base r-base-dev
and then as a regular user use R's install.packages() to install additional packages. This will result in an installation where R and it's base packages are accessible to all but owned by root (and therefore difficult for a regular user to update / mess up) and other packages belong to the regular user (and hence easy to update).
Some packages may have system dependencies, e.g., XML requires the libxml2 and libcurl libraries. The '-dev' version of these libraries also need to be installed, most easily via apt-get
sudo apt-get install libxml2-dev libcurl4-openssl-dev
It may be that your version of apt knows nothing about r-base / r-base-dev. You should then follow the section 'Installing R-devel or a release branch from svn' in the document you mention; skip over the instructions in the 'R-devel' section, and instead follow 'r-patched'.

RStudio installation failure under Debian sid: libgstreamer dependency problems

I use Debian sid (amd64), rolling updates as often as weekly. I downloaded recently the desktop version 0.99.902 of RStudio from their offical site and issued (as root, of course):
dpkg -i rstudio-0.99.902-amd64.deb
to no avail:
dpkg: dependency problems prevent configuration of rstudio:
rstudio depends on libgstreamer0.10-0; however:
Package libgstreamer0.10-0 is not installed.
rstudio depends on libgstreamer-plugins-base0.10-0; however:
Package libgstreamer-plugins-base0.10-0 is not installed.
Newer versions (1.0-0) of these 2 packages are installed on the system, but those older ones (0.10-0) are not available anymore on the official Debian repos.
What should be done to have RStudio installed and fully operational under
Debian sid? I have, of course, installed R debs, from official Debian
repositories, without any issues...
Thanks for any help!
RStudio 1.0.153, released on July 20th 2017, depends on GStreamer 1.0 instead of GStreamer 0.10. It can be installed on modern Debian/Ubuntu without any additional setup, rendering this question and my answer obsolete.
To be more specific, there are two different DEB packages. One is aimed at Ubuntu 16.04 (or later) and Debian 9 (or later), comes only in 64-bit flavor and depends on newer GStreamer 1.0. Another package supports Ubuntu from 12.04 up to 15.10 and Debian 8 and it comes in both 32-bit and 64-bit flavors. This one still depends on older GStreamer 0.10.
Original answer remains below.
As of mid-2016, RStudio has hard dependency on GStreamer 0.10 and there is no way around it. You have to install libgstreamer0.10-0 and libgstreamer-plugins-base0.10-0 to use RStudio.
These packages can be easily pulled in from Debian Jessie (stable). Just add Jessie repository to your sources.list and use apt-pinning to give it lower priority:
# /etc/apt/sources.list:
deb http://httpredir.debian.org/debian jessie main
# /etc/apt/preferences.d/01_release:
Package: *
Pin: release o=Debian,a=unstable
Pin-Priority: 600
Package: *
Pin: release o=Debian,n=jessie
Pin-Priority: 10
Then issue apt-get update and follow up with apt-get install libgstreamer0.10-0 libgstreamer-plugins-base0.10-0.
If you have happened to put RStudio .deb file into local repository, then use apt-get install rstudio and GStreamer0.10 will be pulled in by dependency resolver. This has additional advantage of marking these libraries as automatically installed - they will be subject to automatic removal once RStudio drop them as dependency.
But will that break my system?
No.
Upstream developers designed GStreamer0.10 and GStreamer1.0 as co-installable and able to run at the same time (source). In fact, both were available in Debian repository since September 2012 up to April 2016.
In this pinning setup, packages from Jessie repository will be pulled in only when Jessie is the only provider of requested package. There is no risk of overwriting any package from unstable with older version from stable.
Why does RStudio depend on obsolete library?
Because GStreamer0.10 is the newest version available in both Debian Jessie and Ubuntu 12.04, two distributions they want to support.
RStudio will eventually have to upgrade their dependency to GStreamer1.0, as it will gradually become the only version available. I guess this change may be introduced in spring 2017. First, support for Ubuntu 12.04 will end in April. Rstudio is likely to bump base system requirement to 14.04 - one that has both GStreamer0.10 and 1.0. Second, Debian Stretch - that will have only GStreamer1.0 available - is expected to be released around that time.
I found Miroslaw's answer to be excellent. But, due to the passage of time you will need one more package: libssl1.0.0, so your setup apt-get will look like
apt-get install libgstreamer0.10-0 libgstreamer-plugins-base0.10-0 libssl1.0.0
Download libgstreamer0.10-0 for your machine from any of the mirrors.
Open terminal in the directory where the file is downloaded.
Install it using the command, sudo dpkg -i file.deb. Example sudo dpkg -i libgstreamer0.10-0_0.10.36-1ubuntu1_amd64.deb.
Now open the directory where rstudio.deb is located and install it in the same way.
Download the libraries
http://ftp.br.debian.org/debian/pool/main/g/gstreamer0.10/libgstreamer0.10-0_0.10.36-1.5_amd64.deb
http://ftp.br.debian.org/debian/pool/main/g/gst-plugins-base0.10/libgstreamer-plugins-base0.10-0_0.10.36-2_amd64.deb
Install them with gdebi or dpkg -i and that is it

most common config flags for installing R from source on 64-bit Ubuntu

I'm convinced that using Dirk's package is the best way to install and maintain R on an Ubuntu system. But I want to have some fun and get used to installing R from source.
What are the most common configure flags to use when installing?
Also, if I want to install 2.14.1 and I have 2.14.0 currently installed (which was installed from source), should I first uninstall 2.14.0?
There was a recent thread somewhere about having several versions---one from the apt-get repo, one in /usr/local. Try to find that...
Otherwise, I will roll up 2.14.1 on Friday morning, Michael will do his magic and the repo will have .deb packages of 2.14.1 'real soon', sometimes within a day.
Lastly, you can see which flags are used by getting the package sources for which you just do apt-get source r-base (and that works for any Debian/Ubuntu package that way if you have source references in apt's file.
Edit: By the way, regarding the '64-bit' aspect of your question: Nada. We don't do anything differently. It is "merely" the host OS being more generous with resources. But R finds all it needs to know on its own via its configure etc logic.

Install R packages from binary in Ubuntu Lucid

I've installed R in Ubuntu Lucid with the command
sudo aptitude install r-base
When I try to "install.packages" it seems to download source and then spend ages compiling it. How can I get it to just download and install the binaries, like I'm used to on Windows?
Is there any need to compile the packages myself? I'm running inside a VM so it would be great to keep things as slim as possible.
Thanks
CRAN only distributes source for Unix, in other words no binaries are offered (unlike for Windows). So you simply have to compile the packages locally.
That said, we have been working for a few years now on a system to turn CRAN source packages into Debian binary packages -- see cran2deb / debian.cran.r-project.org. We currently build i386 binaries for Debian testing and are in the process of rewriting the backend to offer amd64 for Debian again and then eventually i386 and amd64 for Ubuntu. This already offers well over two-thousand binary packages but not yet for all the flavours we would like to support eventually.
If and when that goal will be accomplished is hard to say; this is a volunteer effort and the main developer (Charles) recently lost his laptop.
CRAN packages are available in the Ubuntu package repository, but are updated with CRAN only when Ubuntu is updated. If you want to use the latest CRAN version of a package and the repository is not at the same version, you will need to go through the compilation/installation procedure.
Details in the Ubuntu R packages can be found on CRAN, which should give you all the information you require.
As this (the provision of binaries) is all volunteer effort on the part of the CRAN maintainers, R Core and other devoted members of the community (e.g. Dirk, Vincent and Michael for the Debian and Ubuntu packages), the main effort has gone into providing binaries for systems where self-compilation is more difficult as the necessary tools are not easily available, unlike on Linux.

R: apt-get install r-cran-foo vs. install.packages("foo")

When installing R packages (say mcmcpack in this example) under Ubuntu I have the choice between the following two methods of installation:
# Let the distribution's packaging system take care of installation/upgrades
apt-get install r-cran-mcmcpack
# Let R take care of installation/upgrades
install.packages("mcmcpack")
Questions:
Is any of the two ways of installing R packages considered "best practice"?
Assume that I first install.packages("mcmcpack") and later on apt-get install r-cran-mcmcpack - should I expect trouble?
Assume that I first apt-get install r-cran-mcmcpack and later on install.packages("mcmcpack") - should I expect trouble?
Update (some thirteens years later): It is now as easy as it seems if you use for example the wonderful and powerful r2u system I set up last year, and which now provides over 20k binary .deb packages for each of twi Ubuntu LTS releases (currently: 20.04 and 22.04), and is also accessible via install.packages() thanks top bspm. Follow the link to r2u for more.
It's not as easy as it seems.
apt-get update is good if and when
packages exist -- but there are only around 150 or so r-cran-* packages out of a pool of 2100+ packages on CRAN, so rather sparse coverage
packages are maintained, bug free and current
you are happy enough with the bi-annual releases by Ubuntu
install.packages() and later update.packages() is good if and when
you know what it takes to have built-time dependencies (besides r-base-dev) installed
you don't mind running update.packages() by hand as well as the apt-get updates.
On my Ubuntu machine at work, I go with the second solution. But because the first one is better if you have enough coverage, we have built cran2deb which provides 2050+ binary deb packages for amd64 and i386 --- but only for Debian testing. That is what I use at home.
As for last question of whether you 'should you expect trouble': No, because R_LIBS_SITE is set in /etc/R/Renvironment to be
# edd Apr 2003 Allow local install in /usr/local, also add a directory for
# Debian packaged CRAN packages, and finally the default dir
# edd Jul 2007 Now use R_LIBS_SITE, not R_LIBS
R_LIBS_SITE=${R_LIBS_SITE-'/usr/local/lib/R/site-library:\
/usr/lib/R/site-library:/usr/lib/R/library'}
which means that your packages go into /usr/local/lib/R/site-library whereas those managed by apt go into /usr/lib/R/site-library and (in the case of base packages) /usr/lib/R/library.
Hope that clarifies matters. The r-sig-debian mailing list is a more informed place for questions like this.
I'd consider using apt-get best practice since you will get automatic updates through the standard system tools.
Having 2 versions installed might get you into confusing situations: depending on your R setup you could load another package version then you expect -- your private (maybe outdated) one should in general be loaded first.
See above.

Resources