Hm. Maybe we bit ourselves using 4.4.2 as a cutoff when we meant 4.5.0.

Yup. I (apparently incorrectly) assumed that R 4.4.2 would've gained those macros.

I think to close this issue #1341 we need more than #1342 -- we may also need a spot release (say: 1.0.13-1) at CRAN if I understand the report correctly as '1.0.13 cannot be compiled under R 4.4.2'.

I think to close this issue #1341 we need more than #1342 -- we may also need a spot release (say: 1.0.13-1) at CRAN if I understand the report correctly as '1.0.13 cannot be compiled under R 4.4.2'.

FYI, I am seeing this error in a fresh install of R 4.4.2:

> install.packages("Rcpp")
trying URL 'https://cloud.r-project.org/src/contrib/Rcpp_1.0.13.tar.gz'
Content type 'application/x-gzip' length 3435344 bytes (3.3 MB)
==================================================
downloaded 3.3 MB

* installing *source* package ‘Rcpp’ ...
** package ‘Rcpp’ successfully unpacked and MD5 sums checked
** using staged installation
** libs
using C++ compiler: ‘g++ (Debian 14.2.0-7) 14.2.0’
g++ -std=gnu++17 -I"/usr/local/stow/R442/lib/R/include" -DNDEBUG -I../inst/include/  -I/usr/local/include    -fpic  -g -O2   -c api.cpp -o api.o
g++ -std=gnu++17 -I"/usr/local/stow/R442/lib/R/include" -DNDEBUG -I../inst/include/  -I/usr/local/include    -fpic  -g -O2   -c attributes.cpp -o attributes.o
g++ -std=gnu++17 -I"/usr/local/stow/R442/lib/R/include" -DNDEBUG -I../inst/include/  -I/usr/local/include    -fpic  -g -O2   -c barrier.cpp -o barrier.o
In file included from barrier.cpp:31:
barrier.cpp: In function ‘SEXPREC** get_vector_ptr(SEXP)’:
../inst/include/Rcpp/r/compat.h:34:26: error: ‘VECTOR_PTR_RO’ was not declared in this scope; did you mean ‘VECTOR_PTR’?
   34 | # define RCPP_VECTOR_PTR VECTOR_PTR_RO
      |                          ^~~~~~~~~~~~~
barrier.cpp:74:30: note: in expansion of macro ‘RCPP_VECTOR_PTR’
   74 |     return const_cast<SEXP*>(RCPP_VECTOR_PTR(x));                                                       // #nocov end
      |                              ^~~~~~~~~~~~~~~
make: *** [/usr/local/stow/R442/lib/R/etc/Makeconf:204: barrier.o] Error 1
ERROR: compilation failed for package ‘Rcpp’
* removing ‘/usr/local/stow/R442/lib/R/library/Rcpp’

The downloaded source packages are in
        ‘/tmp/Rtmpe8754o/downloaded_packages’
Updating HTML index of packages in '.Library'
Making 'packages.html' ... done
Warning message:
In install.packages("Rcpp") :
  installation of package ‘Rcpp’ had non-zero exit status

Yes that is basically the same report as above.

If you try the branch @kevinushey just committed via remotes::install_github() you will likely succeed.

I accepted and merged the PR so remotes::install_github("RcppCore/Rcpp") will work for you off the main branch.

Updates at r-universe will happen with the hour, that will give you binaries and tarballs too. We will look into CRAN as well.

I now have rocker/r-base:4.4.2 up and confirmed that current Rcpp at CRAN / github CRAN up to 1.0.13.4 runs into this issue, and 1.0.13.5 passes. Now that I can replicate I can work (tomorrow) on a minimal update 1.0.13-1 that passes.

Thanks for everybody's patience while we sort this out.

@eddelbuettel Thank you!

I created a new branch release/1.0.13 with two cherry-picked commits: the required 4.4.2 adjustment correcting use of read-only pointers in the C API to R 4.5.0 or later (the issue at heart here) and the switch to Authors@R without which CRAN would not take the package.

This content should make it to CRAN as 1.0.13-1.

PS It has been shipped, but (as each time) requires a manual approval before even getting to reverse-dependency checks so it may be a few more hours until it is processed. In the meantime, the default branch and its release-candidate version 1.0.13.5 is fine, as are the source and binary packages generated from it at r-universe.

PPS We are at the second manual step now as almost invariably given the nearly 3000 reverse dependencies, "something" comes up as a false positive so we are in state 'waiting' and I replied to the email. Normal progress, should hopefully be on CRAN "soon".

And I just got the 'thanks, on its way to CRAN now' email, this time from Vienna rather than Dortmund.

Closing this now given the hot-fix is on CRAN as 1.0.13-1. Big thank you to @kyleam for the timely and very focussed bug report, to @RCIIIcm for the confirmation, and of course to @kevinushey for putting PR #1342 up to address it.