RobinHankin
commented
1 year ago Dirk Eddelbuettel replies:
(Without BDR/CRAN)
Fellow maintainers,
Pardon the mass-mail intrusion but I was for once more than a little surprised by the bulk email by Brian Ripley. In case you are wondering what to do, in my case the change, as best as I can tell, simply consisted of removing the line AC_PROG_CC in configure.ac as (minimal) src/Makevars.in for package RcppGSL and RDieHarder does not actually set a compiler. I only operate on compiler flags.
If any of you have question, please feel free to reach out (maybe by reply not reply-all) or maybe we start a thread on r-pkg-devel.
Hope this helps, best regards, Dirk
Email from Brian Ripley, 12 Jan 2023:
That is
C50 Cubist GPBayes RDieHarder RPostgreSQL RcppGSL RhpcBLASctl Rmixmod Rrdrand SimInf SymTS eaf excursions fRLR ff float getip git2r gsl gslnls hdf5r island memuse mmap ore poismf randtoolbox rayrender rgeolocate rmatio rnetcarto rngWELL scrypt survSNP xgboost
These show
checking for gcc... gcc
even on platforms using clang as the compiler. Please re-read
https://cran.r-project.org/doc/manuals/r-devel/R-exts.html#Configure-and-cleanup
There need be no 'gcc' compiler, it might be faked (macOS) or very old (Solaris). The aim of a configure script is to test things using the same setup as will be used to compile code in the package.
In several cases you are using a C compiler in configure but a C++ compiler to compile the code: they usually have access to different headers. Looks like this is the case in at least
GPBayes RcppGSL Rmixmod fRLR ff rayrender xgboost
The logs showing
need configure rebuilt with a modern autoconf, which will check C11 (and that or C17 are the default in all the current compilers we know of -- however, that old autoconf test will fail when C23 comes into use).
Please correct before 2023-01-26 to safely retain your package on CRAN.
-- Brian D. Ripley, ripley@stats.ox.ac.uk Emeritus Professor of Applied Statistics, University of Oxford