Reason to require R >= 3.3.0 ?

[ghost]

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 d05744c 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.

[thirdwing]

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

[ghost]

I just replied in #1267 that some change in dmlc-core\include\dmlc\base.h #1267 (comment) helped to solve the building issue with R 3.2. Can we get that change into dmlc?

[thirdwing]

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 dmlc/dmlc-core#124 and dmlc/dmlc-core#143 as reference.

Ideally we should test different tool chains.

[tqchen]

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?

[thirdwing]

This can be done if I have time. But it seems better to pass all CRAN check first.

[thirdwing]

@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.

[tqchen]

we do need to define fopen64 because it is used in later code, but maybe not with prefix std

[thirdwing]

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.

[tqchen]

Sounds good, I think Rtools compatibility is more important, and the other windows builds will be recommended to direct to CMake based builds

[thirdwing]

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.

[hetong007]

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?

[dchiu911]

Hi All,

I also have to use R 3.2.5 and thus cannot install xgboost. Any updates regarding this issue?
Thanks!

[thirdwing]

After making a new release, I will fix this.

[wayne923]

Hello I am in the same boat, and I was wondering if there is a workaround to letting R 3.2 install xgboost?

[khotilov]

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.

[wayne923]

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:
#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!

[pommedeterresautee]

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)