A small example of the problem is?
#define USE_RINTERNALS 1
#include <R.h>
#include <Rinternals.h>
#include <Rdefines.h>
static s_object* obj = NULL;
Prior to 2021-07-20, with svn 80639, this compiled but after, svn 80647,
that I get
$ gcc -I"/mnt/c/R/R-svn/trunk/src/include" -I. ? -I/usr/local/include ?
-fpic ?-g -O2 -flto -c s_object.c 2>&1
In file included from s_object.c:5:
/mnt/c/R/R-svn/trunk/src/include/Rdefines.h:168:33: error: unknown type name
?SEXPREC?
? 168 | #define s_object ? ? ? ? ? ? ? ?SEXPREC
? ? ? | ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ^~~~~~~
s_object.c:7:8: note: in expansion of macro ?s_object?
? ? 7 | static s_object* obj = NULL;
? ? ? | ? ? ? ?^~~~~~~~
On Thu, Jul 22, 2021 at 10:18 AM Bill Dunlap <williamwdunlap at gmail.com>
wrote:
I think the problem with RPostgreSQL/sec/RS-DBI.c comes from
some changes to Defn.h and Rinternals.h in RHOME/include that
Luke made recently (2021-07-20, svn 80647).? Since then the
line? ?#define s_object SEXPREC
in Rdefines.h causes problems.? Should it now be 'struct SEXPREC'?
-Bill
On Thu, Jul 22, 2021 at 7:04 AM I?aki Ucar <iucar at fedoraproject.org>
wrote:
Hi,
On Thu, 22 Jul 2021 at 15:51, Hannah Owens
<hannah.owens at gmail.com> wrote:
>
> Hi all,
> I am working on an update to a package I have on CRAN
> latest release attempt didn?t pass incoming automated
> is an outstanding error. Additionally, there are some
> like to get rid of, if anyone has suggestions.
>
> The killing error is in r-devel-linux-x86_64-debian-gcc,
> required but not available: 'BIEN', 'taxize',
>
> I don?t understand this, as it is the only system that
> and the packages mentioned are available via CRAN. Any
> Additionally, there are multiple platforms
> (r-devel-linux-x86_64-fedora-clang;
r-devel-linux-x86_64-fedora-gcc;
> r-devel-windows-x86_64-gcc10-UCRT;
> r-release-macos-arm64; r-release-macos-x86_64;
r-oldrel-macos-x86_64) where
> two notes pop up:
>
> NOTE 1: Namespace in Imports field not imported from:
> Imports should be used.
>
> The package does use bit64. Any tips on how to address
this note?
Are you sure? Your NAMESPACE file does not import(bit64)
nor
importFrom(bit64,) anything.
> NOTE 2: Found 6 marked UTF-8 strings.
>
> I presume this is thrown because of the small sample
> in the package, but why is it not thrown for all the
platforms?
Not all the checks are necessarily done in all the
platforms. You can
silence this NOTE by converting the offending strings in
your datasets
to ASCII and resaving them.
--
I?aki ?car