I'm on Mac OSX 10.13.6
If I do:
library("devtools")
install_github(repo = "bryanhanson/ChemoSpec#master")
I get the following error:
install_github(repo = "bryanhanson/ChemoSpec#master") Downloading
GitHub repo bryanhanson/ChemoSpec#master from URL
https://api.github.com/repos/bryanhanson/ChemoSpec/zipball/master
Installation failed: error:1407742E:SSL
routines:SSL23_GET_SERVER_HELLO:tlsv1 alert protocol version
I get similar but not identical errors if I try to use pkgdown::build_site() but for now let's set that aside; I think it will prove to arise from the same problem.
I've done a lot of research, and I think the error must reside with one or more of the following: curl, git and/or openssl. I know Mac has its own versions of openssl and curl, and one might need to take steps to access them. My git is up-to-date (2.19.0), I have used Homebrew to update everything it wants to update. This includes curl and openssl but Homebrew does not automatically link to it so as to avoid interfering with the native Mac versions (They are "keg-only"). I have however within R put the Homebrew versions on the path and it doesn't fix the error. R and all R packages are up-to-date.
My research shows this problem has plagued others but none of the solutions have worked. It appears as though the problem is related to deprecated protocols, for instance I've set git config --global --add http.sslversion=tlsv1.2 to no avail.
Finally, this arose about a month ago but I don't know what I did that caused it.
Sorry this is not much to go on. Hopefully some of you experts will know how to troubleshoot.
I'd highly suggest using homebrew to install a proper (Apple is terrible about some kinds of updates) version of curl/libcurl and then re-install the curl and httr packages. (if you do install homebrew, you should also run brew update and brew upgrade on a regular basis).
Related
I am using R on Windows to connect to a PostgreSQL database hosted on AWS. The database is set up using forcessl = 1 - this means that any connection needs to be set up with sslmode=require.
The base RPostgreSQL package does not provide any exposure to ssl options. This has been raised as an issue many times (see here, here, here and here)
I know there is a workaround using the RPostgres package, but for other functionality reasons I would much prefer to use the RPostgreSQL package.
A few answers (e.g. here) have proposed using a modified dbname to connect with ssl like so:
dbConnect(dbDriver('PostgreSQL'),
dbname = 'dbname=foobar sslmode=require', # modified dbname
host = 'foobar.rds.amazonaws.com',
port = 5439,
user = 'foobar',
password = 'foobar')
But this did not work for me using the CRAN version of the package. This led me to a recent issue raised on the RPostgreSQL github: https://github.com/tomoakin/RPostgreSQL/issues/88
The initial user was able to use the modified dbname method when he compiled the package from source. On Windows, using the latest source package (0.6.2) compiled with RTools, I get the following error when I run the modified dbname code:
Error in postgresqlNewConnection(drv, ...) :
RS-DBI driver: (could not connect xxxxx.rds.amazonawss.com:5432 on dbname "xxxxxxx": sslmode value "require" invalid when SSL support is not compiled in
)
From this and the rest of the thread, it looks like SSL is not possible from current source in both Windows and Mac. However, the developer suggests:
If you compile in a environment where libssl and libpq was made SSL activated form, then the driver can use SSL.
I think this means I could manually download the libs and compile myself, but I am not sure if it is a quick fix or if it would require significant rewriting of the package. Any help or pointing in the right direction would be much appreciated. How can I do this in a safe, repeatable way?
I was able to solve this for the El Capitan macOS R users in my office, by doing the following:
Remove RPostgreSQL R package if you already have installed. Methods vary on how to do this, but from either R.app console or R in Terminal, type remove.packages('RPostgreSQL')
Make sure you have Homebrew installed, and from Terminal run: brew install libpq openssl
Open R.app, and from the Packages & Data menu, select Package Installer.
From the first drop-down menu, choose CRAN (sources) (choose mirror closest to you if you haven't used this before).
Using package search, find RPostgreSQL and for the options below, keep At System Level checked, and check Install Dependencies, then click Install Selected.
Quit out of all R and RStudio programs, and try using the new from source installed RPostgreSQL package.
DISCLAIMER: If you have heavy compile dependencies on OpenSSL or libpq for other programs, I have no idea how doing the above may break other programs.
Building on Windows is a can of worms. See R-Admin Windows Toolset. The only openSSL binaries for windows are from unknown developers. Building and installing openSSL on windows is another can of worms that you will need to research. It might be easier to install openSSL inside the R Windows build environment, but I have no experience with that.
EDIT: It turns out that when installing postgres on Windows, postgres installs openSSL. That means that the central problem on Windows is installing the Windows Toolset for R, installing postgres, then pointing the R build system to libpq.
Another solution would be to run linux in a virtual machine under windows. Here is one way to Install linux on Windows. With linux, depending on the distribution, you would only need to do something like the following from the linux command line (for a RedHat variant of linux):
sudo yum install openSSL
sudo yum install postgresql96
sudo yum install R
Line 2 installs libpq which is required for RPostgreSQL. It is libpq which must be compiled with openSSL. You will only be installing and using the PostgreSQL client, not the server and will also get psql. There might be other packages required, see R linux toolset. Normally, these will get pulled in with the above and should not be a problem.
RPostgreSQL contains a version of libpq, but the compile script does not look like it checks for openSSL, at least not on macOS. So it is important to get a system provided libpq installed.
It is also important for the RPostgreSQL configure script to find pg_config, which is installed when postgres client is installed. Not sure about windows through. So make sure pg_config is in your path. Type pg_config to find out.
Now you need to download and compile RPostgreSQL. To start R, type the following at the linux terminal.
R
Then from within R, get, compile and install RPostgreSQL:
install.packages("https://cran.r-project.org/src/contrib/RPostgreSQL_0.6-2.tar.gz", repo=NULL, type="source")
This should compile and install this version of RPostgreSQL. This last line should also work in windows if you have the windows tools installed correctly.
Hopefully, this gives you some ideas.
Trying to compile R-3.3.2 on Debian Jessie, all dependencies are installed. However the ./configure script complains about the zlib/bzip2 library versions not matching with the minimum requirement.
Minimum version required:
zlib: 1.2.6 (installed version: 1.2.11)
bzip2: 1.0.6 (installed version: 1.0.6)
After looking at the parts of configure script checking the library versions, it seems that it compares versions with strcmp or strncmp. Since "1.2.11" is lexicographically smaller that "1.2.6" it return a non-zero value indicating that the match failed. Besides, it just compares the first 5 characters which is also not what it is intented. So, it's a bug in configure script. Changing the script fixed the issue.
For zlib, find this line:
exit(strncmp(ZLIB_VERSION, "1.2.5", 5) < 0);
Change it to:
exit(ZLIB_VERNUM < 0x1250);
I had some issues installing R myself, specifically with the error
checking for BZ2_bzlibVersion in -lbz2... no
I had to install libbz2-dev to get that error to go away.
Unfortunately, I came across a few more issues while running ./configure and had to do a little more digging to find out how to solve it.
Discussion on issue
After reading that, I had realized I had to install a couple packages like libcurl4-openssl-dev, libpcre3, and liblzma-dev to finally finish the configuration.
The cited link suggested
At this stage you could have as well tried to install R 3.2.0RC ...
R-devel has not yet diverged much.
Personally, I think that installing an older version to resolve dependency issues reeks of laziness, but that's just my two cents.
I am trying to install R on a RedHat server with no connectivity to the Internet. (sigh)
Initially, I tried with R meta package from EPEL (http://fedoraproject.org/wiki/EPEL).
Due to dependency requirements, I downloaded dependancies Rcore ,libRmath, etc...
Each time it prompts for a dependency, I download, transfer and install.
This takes time and manual effort.
Is there a cleaner way to do this than the manual download, transfer and install of every single dependency?
Note: The server has no internet connection, so yam is not helpful.
Have you thought of simply compiling R from source?
I usually do that, and it is relatively painless.
The thing is that when you do the ./configure step
you should get a list of all librarires that you
need before you issue make.
It might be less of a hazzle than the redhat install
you are doing.
I believed we are unable install R without online (unless there was someone download the installer and pass to you). You can refer to Setup ®Studio Server (CentOS/RHEL 7). Hope this helps.
One thing you could do is install R on a server with internet access.
Install Rtools.
Then you install all the packages you need with the option destdir of install.packages.
You will then get a folder with all the packages you will need.
My Fedora system (Fedora 20, all up to date) has just had R updated to version 3.1.0. Since then, I've had issues installing multiple packages. glmnet failed previously, and now I'm having trouble with treemap. More specifically, I get an error during treemap installation that httpuv has zero exit status.
I never had issues with the previous version of R. Any reason this version should have such problems??
There could be many causes to do with your OS, version, permissions, other installed packages/software, etc, etc. Without seeing the full error message it's hard to know.
One possibility specific to httpuv is root privileges. I've noticed a few threads on various forums when searching for installation errors with this package and Linux, many of them mentioning root v. non-root issues. In another case, libuv needed to be upgraded.
I encounter package installation problems daily and I have some more general work-arounds as well. Hopefully one of these will solve your problem.
Install the package from source
download.file(url="http://cran.r-project.org/src/contrib/httpuv_1.3.0.tar.gz", destfile = "httpuv.tar.gz")
install.packages("httpuv.tar.gz", type = "source", repos = NULL)
Install using devtools via GitHub if the package supports it
Install RTools and re-try your package installation
Install an older version of the package
If those above do not work, then I dig deeper by referring to advice given to me by a VP of IT in my company. These comments were made in reference to frequent package installation problems I encountered when switching from Windows to Solaris:
There are two types of install/make problems. Missing .h files
and/or missing .so/.a libs. The reason for these are multiple:
1.- the package that delivers these is not installed. This means that those files cannot be found anywhere in the /usr tree. Solution is
install right package, make sure the files are there
2.- the includes are not found by the install configurator. This means some environment variable or install option is not properly set (this
is our case for RODBC). Figuring out which variable to set is
challenging without looking at the package documentation [fortunately, documentation is not hard to find!]
3.- the libs are not in the LD_LIBRARY_PATH, easy to fix.
4.- There is a deeper compile/link error, meaning the package is not compatible with the rest of the sw, or has not been properly ported.
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.