Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cannot install lidR on R 3.6.3 due to cpp 14+ requirements #786

Open
quinn-r88 opened this issue Nov 7, 2024 · 4 comments · May be fixed by #787
Open

Cannot install lidR on R 3.6.3 due to cpp 14+ requirements #786

quinn-r88 opened this issue Nov 7, 2024 · 4 comments · May be fixed by #787

Comments

@quinn-r88
Copy link

Problem

Attempting to install lidR on R 3.6.3 yields the following errors:

In file included from concaveman/concaveman.h:24,
                 from convaveman.cpp:2:
concaveman/rtree.h: In member function ‘void rtree<T, DIM, MAX_CHILDREN, DATA>::insert(rtree<T, DIM, MAX_CHILDREN, DATA>::data_type, const bounds_type&)’:
concaveman/rtree.h:44:21: error: ‘make_unique’ is not a member of ‘std’
   44 |       auto r = std::make_unique<type>(data, bounds);
      |                     ^~~~~~~~~~~
concaveman/rtree.h:44:21: note: ‘std::make_unique’ is only available from C++14 onwards
concaveman/rtree.h:44:37: error: expected primary-expression before ‘>’ token
   44 |       auto r = std::make_unique<type>(data, bounds);
      |                                     ^
concaveman/rtree.h:67:22: error: ‘make_unique’ is not a member of ‘std’
   67 |     auto leaf = std::make_unique<type>(best_child.get().data(), best_child.get().bounds());
      |                      ^~~~~~~~~~~
concaveman/rtree.h:67:22: note: ‘std::make_unique’ is only available from C++14 onwards
concaveman/rtree.h:67:38: error: expected primary-expression before ‘>’ token
   67 |     auto leaf = std::make_unique<type>(best_child.get().data(), best_child.get().bounds());
      |                                      ^
make: *** [/usr/lib/R/etc/Makeconf:177: convaveman.o] Error 1
ERROR: compilation failed for package ‘lidR’
* removing ‘/home/qbowers/R/x86_64-pc-linux-gnu-library/3.6/lidR’

Steps to Reproduce

  1. Install lidR dependencies per the README
    • sudo add-apt-repository ppa:ubuntugis/ubuntugis-unstable
    • sudo apt-get update
    • sudo apt-get install libgdal-dev libgeos++-dev libudunits2-dev libproj-dev libx11-dev libgl1-mesa-dev libglu1-mesa-dev libfreetype6-dev libxt-dev libfftw3-dev
  2. Install the terra package from R-Universe (the CRAN version similarly does not install on R 3.6.3)
    • install.packages('terra', repos='https://rspatial.r-universe.dev')
  3. Install lidR
    • packages.install('lidR')

My Setup

  • OS: Ubuntu 20.04
  • R: 3.6.3

Commentary

I know that 3.6.3 is reasonably out of date, however the lidR CRAN package still claims to support R versions as old as 3.5. Ideally a user should not have to look up the history of R's default compiler settings to install a package if it claims to be supported. Would it be possible to either change the CRAN package to report that it only supports R 4+, or else add back the C++ version requirements somewhere, perhaps as described here?

Thanks!

@Jean-Romain
Copy link
Collaborator

The issue isn’t with R 3.6 itself but with the fact that it compiles by default with C++11, whereas lidR requires C++14. Previously, this was enforced by explicitly adding the C++14 flag in the Makevars file. However, with the transition to R 4.0, then 4.1, and subsequent versions, CRAN has progressively moved to default C++ standards—first C++11, then C++14, and now C++17. CRAN specifically requested that I remove the explicit C++14 flag from Makevars: 072d031. As a result, without this explicit C++14 specification, it compiles under C++11 with R 3.6. While R 3.6 does support C++14, the recent CRAN policy changes mean that this information is no longer enforced in older R versions.

@quinn-r88
Copy link
Author

Yeah, I did see those spec changes. I notice though that other CRAN packages are still able to compile with C++14 or higher, even on old R versions. This article describes using a configure script to the same effect, which CRAN seems to prefer - why they would prefer that over just stating the c++ version I cannot say, but at least it works.

Here's one example of such a script: tidyverse/readxl#722

Or alternatively, you could just change the description to require R 4.0+ or something

@Jean-Romain
Copy link
Collaborator

Thank you for sharing the link. Can you make a PR ?

@quinn-r88 quinn-r88 linked a pull request Nov 12, 2024 that will close this issue
@quinn-r88
Copy link
Author

Done! Check out #787 when you've got a chance.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants