Rcpp 1.0.13 build error with R 4.4.2 (VECTOR_PTR_RO)

[kyleam]

I can successfully build and install Rcpp 1.0.13 with an R built from the current trunk (revision 87283). However, with an R version built from an R-4-4-branch checkout (revision 87276), I get the following error:

* installing *source* package ‘Rcpp’ ...
** package ‘Rcpp’ successfully unpacked and MD5 sums checked
** using staged installation
** libs
using C++ compiler: ‘g++ (Ubuntu 9.4.0-1ubuntu1~20.04.2) 9.4.0’
g++ -std=gnu++17 -I"/tmp/r-install/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"/tmp/r-install/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"/tmp/r-install/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: *** [/tmp/r-install/lib/R/etc/Makeconf:204: barrier.o] Error 1
ERROR: compilation failed for package ‘Rcpp’
* removing ‘/tmp/rcpp-install/lib/Rcpp’

9c5f71c (use read-only variants of {STRING/VECTOR}_PTR (#1317), 2024-07-11) added the following conditions:

#if R_VERSION >= R_Version(4, 4, 2)
# define RCPP_STRING_PTR STRING_PTR_RO
#else
# define RCPP_STRING_PTR STRING_PTR
#endif

#if R_VERSION >= R_Version(4, 4, 2)
# define RCPP_VECTOR_PTR VECTOR_PTR_RO
#else
# define RCPP_VECTOR_PTR VECTOR_PTR
#endif

While it looks like STRING_PTR_RO has been around since R 3.5.0, VECTOR_PTR_RO isn't available until trunk@86694 (wch/r-source@85ee9ad34c). VECTOR_PTR_RO is present in trunk but not the upcoming R 4.4.2 (i.e. the condition above is incorrect).

# confirmation by inspecting svn checkouts
$ grep VECTOR_PTR_RO R-4-4-branch/include/Rinternals.h trunk/include/Rinternals.h
trunk/include/Rinternals.h:const SEXP *(VECTOR_PTR_RO)(SEXP x);

# confirmation by inspecting wch/r-source
$ git for-each-ref --contains=85ee9ad34cff164ce3e7038f51ce0eee5db90469 refs/remotes
c06d2576f10fc82a4e06120df79f32eeaf044f99 commit	refs/remotes/origin/HEAD
37f8078802e29f98db40a6b287275a5043e16b06 commit	refs/remotes/origin/R-more-NS
c06d2576f10fc82a4e06120df79f32eeaf044f99 commit	refs/remotes/origin/trunk

[ +cc @kevinushey ]

[eddelbuettel]

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

[kevinushey]

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

[eddelbuettel]

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

[RCIIIcm]

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

[eddelbuettel]

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.

[eddelbuettel]

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.

[eddelbuettel]

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.

[kyleam]

@eddelbuettel Thank you!

[eddelbuettel]

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

[eddelbuettel]

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

[eddelbuettel]

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.

[barracuda156]

Somehow I get a similar error with RJSONIO and R 4.4.3: duncantl/RJSONIO#30

[eddelbuettel]

@barracuda156 :

• As RJSONIO does not use Rcpp I am not sure why you post here
• I addressed the issue in a post to the r-devel list containing a very short patch
• @kurthornik says he will release an update RJSONIO shortly has already released an updated RJSONIO

[barracuda156]

@eddelbuettel Thank you very much!