[R-pkg-devel] Question about Debian installation error

[Yu Yang]

Hi Ivan, 

  Thank you so much for your help! I have fixed the issue following your advice!

  May you have a great day!

Best,
Yu


> On Oct 1, 2024, at 6:39 AM, Ivan Krylov <ikrylov using disroot.org> wrote:
> 
> Hi Yu and welcome to R-package-devel! You're now part of the team as
> well.
> 
> В Mon, 30 Sep 2024 21:30:44 -0400
> Yu Yang <yuyang.stat using gmail.com> пишет:
> 
>>  I recently updated my package “glmtlp” to meet the “_PACKAGE”
>> requirement and to deal with the “noRemap" requirement. I only
>> modified the DESCRIPTION and glmtlp-package.R file and fixed a few
>> typos. R CMD check showed no errors in my local machine (MacOS), but
>> when I submitted to CRAN, it said installation error on Debian. 
>> 
>>  The log file is at:
>> https://win-builder.r-project.org/incoming_pretest/glmtlp_2.0.2_20240930_002619/Debian/00install.out.
> 
> Thank you for providing the link to the failing example. The
> screenshot(?) didn't come through [1]; this mailing list only accepts
> plain text messages and a restricted set of attachment types, so it's
> best to compose in plain text as well.
> 
> The reason your package is failing is because your C++ code calls R API
> functions by their short ("remapped") names, and this will no longer
> work in the next version of R. This has been mentioned in the news for
> R-devel [2,3]. The remapping is described in "Writing R Extensions",
> chapter 6 [4] (and a bit more at the end, shortly before chapter 7).
> 
> In short, to reproduce the error outside of R-devel, you need to
> #define R_NO_REMAP before #including R API (or provide the -DR_NO_REMAP
> command-line switch to the compiler), and then fix it by finding every
> remapped name in your code and replacing it by the full name (typically
> by prepending Rf_ to it).
> 
> You're not the first package author to have problems with C++ code due
> to R_NO_REMAP [5]. There's now an incomplete, unofficial set of
> manpage-style API documentation (made possible by Luke Tierney's effort
> to export a list of API functions programmatically via tools:::funAPI)
> where you can find both full and remapped names for most of "ordinary"
> R API and slightly less than a half of experimental R API [6]. Thanks
> to Erez Shomron, there's also information about when a lot of the
> functions had been introduced.
> 
> The reason we have remapping in the first place is that for historical
> reasons, R API contained a lot of functions with "ordinary" names, such
> as "length", which conflicted with other C functions named "length" in
> the same namespace. This problem has been solved at the cost of
> introducing a more manageable problem by remapping: the "real" names of
> the conflicting functions now start with Rf_ (e.g. "Rf_length"), and to
> avoid breaking all existing code (including R itself), R uses the C
> preprocessor to replace the short names with the full names on the fly:
> "#define length Rf_length" and so on.
> 
> Unfortunately, that still leads to conflicts when you need to use
> something named "length" (e.g. [7]) in a source file that #includes the
> R API. You type s.length(), and the preprocessor patches that to
> s.Rf_length(), and everything breaks. Since C++ code is the most
> affected by this, the R developers are now disabling it for all C++
> code.
> 
> Hope this helps!
> 
> -- 
> Best regards,
> Ivan
> 
> [1]
> https://stat.ethz.ch/pipermail/r-package-devel/2024q4/011121.html
> 
> [2]
> https://developer.r-project.org/blosxom.cgi/R-devel/NEWS/2024/04/14#n2024-04-14
> 
> [3]
> https://stat.ethz.ch/R-manual/R-devel/doc/html/NEWS.html
> 
> [4]
> https://cran.r-project.org/doc/manuals/R-exts.html#The-R-API
> 
> [5]
> https://stat.ethz.ch/pipermail/r-package-devel/2024q2/010913.html
> 
> [6]
> https://aitap.codeberg.page/R-api/#nrows
> https://aitap.codeberg.page/R-api/#XLENGTH
> https://aitap.codeberg.page/R-api/#allocVector
> 
> [7]
> https://en.cppreference.com/w/cpp/string/basic_string/size