I have to use R 3.2 in my workplace. But latest xgboost R package 0.6-3 requires R >= 3.3.0
I see 0.6-2 was requiring >= 2.15.1, and there was a commit https://github.com/dmlc/xgboost/pull/1920/commits/d05744cd5a513dfb6922c7f23e7a0f75d2bc81bd mentioning bumping to R 3.1.0.
I wonder if there's any reason to require 3.3.0. If not can we get it down to 3.1.0 or 3.2.0? Thanks.
The requirement R >= 3.3.0
is basically to use the new Rtools with GCC 4.9.
The package can't compile using the old Rtools: https://www.r-project.org/nosvn/R.check/r-oldrel-windows-ix86+x86_64/xgboost-00check.html
I just replied in #1267 that some change in dmlc-core\include\dmlc\base.h https://github.com/dmlc/xgboost/issues/1267#issuecomment-231975899 helped to solve the building issue with R 3.2. Can we get that change into dmlc?
I don't have strong opinions on this. However, we used to have some problems in fopen64
. Different tool chains might have different definition. See https://github.com/dmlc/dmlc-core/pull/124 and https://github.com/dmlc/dmlc-core/pull/143/ as reference.
Ideally we should test different tool chains.
If possible, I think it might be helpful to keep backward compatibility on g++4.6.
Just to make sure we don't break things. @thirdwing can you look into this?
This can be done if I have time. But it seems better to pass all CRAN check first.
@tqchen @hetong007 We can support old Rtools by removing these three lines https://github.com/dmlc/dmlc-core/blob/master/include/dmlc/base.h#L138-L140
But we need to test some more distribution of MinGW.
we do need to define fopen64 because it is used in later code, but maybe not with prefix std
I know what you mean.
My suggestion is that (1) we provide a recommended version of MinGW-w64 (for example, TDM distribution from http://tdm-gcc.tdragon.net/) and add it into our documents (https://github.com/dmlc/xgboost/blob/master/doc/build.md#building-on-windows); (2) besides this MinGW-w64, we also support the Rtools with GCC4.6.3 and GCC4.9.2.
Sounds good, I think Rtools compatibility is more important, and the other windows builds will be recommended to direct to CMake based builds
I think it is good enough if we guarrante xgboost can compile using two Rtools and one MinGW. I will let you know after testing.
I'm planning a new CRAN submission for R 3.4.0.
Currently we still require R 3.3.0, any progress on releasing the constraint?
Hi All,
I also have to use R 3.2.5 and thus cannot install xgboost. Any updates regarding this issue?
Thanks!
After making a new release, I will fix this.
Hello I am in the same boat, and I was wondering if there is a workaround to letting R 3.2 install xgboost?
As a workaround, you might try installing it from source where you would first modify the R-package/DESCRIPTION file to have the "R (>= 3.2.0)" dependency. You would still need to use a C++11 compatible compiler though.
Hey Khotilov, thanks for the quick response.
Based on your explanation I found an older commit and tried installing like this:
install_github('dmlc/xgboost',subdir='R-package', ref = "7948d1c")
However, it fails with the following warning message.
Warning message:
GitHub repo contains submodules, may not function as expected!
I've searched around and found thirdwing saying devtool doesn't support submodules, and found a long explanation on how to supposedly do this:
https://github.com/dmlc/xgboost/issues/776
They seem to be using cygwin to install from a github clone. I haven't yet tried this; however, in the end, I need to install it on a EC2 instance which is Linux so I'm very hesitant to try it out. I would very much appreciate it if anyone can provide me some more guidance on what is the best way to install an older version that works on R 3.2.
Thank you so much!
I would do a clone of the repo and build from there.
To get the submodules, please look at : https://github.com/dmlc/xgboost/blob/master/doc/build.md
Then you can easily do the modification described by @khotilov
(Building the package will be easy from Rstudio)
Most helpful comment
After making a new release, I will fix this.