[R-pkg-devel] FW: [CRAN-pretest-archived] CRAN submission RIBMDB 1.0.0

[Ivan Krylov]

Hello Binit Kumar,

On Wed, 17 Feb 2021 15:12:53 +0000
Binit Kumar <bkumar using rocketsoftware.com> wrote:

> Error: Ld:/Compiler/gcc-4.9.3/local330/lib
> -LD:/RCompile/recent/R/bin/i386 -lR clidriver/bin/db2app64.dll: file
> not recognized: file format not recognized
> 
> Why is db2app64.dll a non recognized file?

The package is being built for i386 (32-bit) subarchitecture, but the
64-bit dll is being linked to it. I think that the correct way to
identify the target sub-architecture is to inspect the R_ARCH
environment variable from configure.win (in R code, use getenv()).

This is described in WRE 1.2:
<https://cran.r-project.org/doc/manuals/R-exts.html#Configure-and-cleanup>.

> Error: ** testing if installed package can be loaded from temporary
> location
> 
> Error: package or namespace load failed for 'RIBMDB' in
> dyn.load(file, DLLpath = DLLpath, ...):
> 
>  unable to load shared object
> '/srv/hornik/tmp/CRAN/RIBMDB.Rcheck/00LOCK-RIBMDB/00new/RIBMDB/libs/RIBMDB.so':
> 
>   libdb2.so.1: cannot open shared object file: No such file or
> directory

The bigger problem is trying to manually write under R.home() during
installation. This is not allowed by the CRAN policy and may lead to
problems. (Imagine what would happen if two different packages tried to
write to file.path(R.home(), 'clidriver') and for some reason succeeded
despite it's usually not writable for the end-user on Unix-alikes...)

Instead, you could try to (1) use ./configure to extract the
library to src/ and link to it from there and (2) provide a
src/install.libs.R file to copy libdb2.so from src/ to the same
directory where the package shared object is installed. This still may
be insufficient as you might have to instruct the dynamic linker to look
for libdb2.so in the same directory when the package shared object is
loaded by R; on some compilers this may be done by passing the
-rpath='$ORIGIN' argument to the linker, but this is very
platform-dependent (no idea whether it's going to work on Solaris, for
example).

See WRE 1.1.5 for more info on install.libs.R:
https://cran.r-project.org/doc/manuals/R-exts.html#Package-subdirectories

In short, linking an R package to a binary dependency not provided by a
system package is painful, but not explicitly prohibited by CRAN policy
("Source packages may not contain any form of binary executable code",
and yours downloads binaries when it's built, but doesn't contain any;
"Downloads of additional software <...> as part of package installation
<...> should only use secure download mechanisms", which yours does).

-- 
Best regards,
Ivan