[R-pkg-devel] Error in inDL(x, as.logical(local), as.logical(now), ...) unable to load shared object

[Tomas Kalibera]

On 12/27/21 4:04 PM, Ezra Tucker wrote:
> Hi Tomas,
>
>
> Thanks again for all your great info. One last question- and maybe it's
> a stupid one. You mention the JAGS package-- I've been using xml2 as my
> kind-of template. Installing it on linux for example will fail unless
> you have the libxml2-dev package installed (at least for debian-based),
> whereas for windows it just goes and downloads the dll as part of the
> install process. Why would/should this package NOT just perform this
> action for linux as well (namely, automatically download the precompiled
> .so from somewhere else and package it in so you don't need root
> privileges to install the package)? Is this just a difference in install
> philosophy between linux and windows?

Hi Ezra,

Dirk responded in detail re Unix.

On Windows, static libraries (not dynamic) are used by R and are part of 
the toolchain (Rtools42 for R-devel and R 4.2), you just link the 
libraries from there via PKG_LIBS in your Makevars.ucrt or Makevars.win 
file. See for example rgdal for the recommended way how to do this, and 
[1] for a description.

Best
Tomas

[1] https://developer.r-project.org/WindowsBuilds/winutf8/ucrt3/howto.html

>
>
> Thanks again!
>
> -Ezra
>
> On 12/23/21 17:20, Tomas Kalibera wrote:
>> On 12/23/21 4:52 PM, Ezra Tucker wrote:
>>> Hi Tomas and Dirk,
>>>
>>>
>>> Thanks for your suggestions! Between the two, got it working. I didn't
>>> know Windows didn't do rpath, I think that you're right that setting the
>>> PATH would have helped. I haven't seen that in an R package before, so I
>>> did what was in the Rblpapi package, which was creating a couple of
>>> copies of the dll in question.
>> Well it is very exceptional that packages link to an external DLL, only
>> very few CRAN packages do (another example is packages linking to JAGS).
>> I know about these as some of them caused trouble with staged
>> installation and other with the switch to UCRT, they certainly make
>> maintaining and improving R harder. They typically won't work correctly
>> with encodings on Windows. The C++ interface is particularly tricky and
>> fragile. So, one thing is getting this to work in your package you need
>> another question is whether at all it should be published on CRAN, and
>> if that was your plan that'd be best discussed with the CRAN repository
>> maintainers. In some cases there is no other way thank linking to an
>> external DLL, but the question is always whether such package should be
>> on CRAN.
>>> On a related note, in Rblpapi Makevars.win line 47 it's downloading and
>>> extracting the compiled library from GitHub. My understanding is that
>>> one shouldn't include pre-compiled libraries in R packages for security
>>> reasons, at least not for submitting to CRAN. Is doing it this way a
>>> good way around that?
>> No, those concerns apply and are unrelated in principle to using an
>> external DLL. My understanding is that this was also an exception
>> discussed with the CRAN repository maintainers, but I don't know the
>> case specifically.
>>
>> Best
>> Tomas
>>
>>
>>> Thanks again!
>>>
>>> -Ezra
>>>
>>>
>>> On 12/23/21 09:34, Dirk Eddelbuettel wrote:
>>>> On 23 December 2021 at 11:07, Tomas Kalibera wrote:
>>>> | You can have a look at CRAN package Rblpapi which is using an external DLL.
>>>>
>>>> Yes with one big caveat: You have to make sure the library follows what is
>>>> the "hour-glass pattern": it needs to have an internal (the "narrow" part) C
>>>> library covering the wider underlying library and offered via a wider header.
>>>>
>>>> Only C linkage works across different compiler families. You just cannot use
>>>> a Virtual C++-made Windows DLL from R's MinGW g++ compiler with C++.
>>>>
>>>> But you can use C linkage.  So some libraries (such as the Bloomberg API used
>>>> in Rblpapi and the TileDB API used in the tiledb package (when not using a
>>>> local build) can use a library following the hourglass pattern:
>>>>
>>>>      - "wide" bottom layer (may be C++ or C) with the core implementation
>>>>
>>>>      - "narrow" C layer accessing the bottom and priving an API providing via C
>>>>        which profits from C's portable foreign function interface
>>>>
>>>>      - "wide" layer on top via a header-only C++ file accesssing the C and
>>>>        which the C++ compiler optimizes away so that the C API is used for linking
>>>>
>>>> Sounds complicated, but works great.
>>>>
>>>> Good detail is in a hour-long but not-too-technical talk here
>>>>
>>>>      https://www.youtube.com/watch?v=PVYdHDm0q6Y
>>>>
>>>> and slides etc are here
>>>>
>>>>      https://github.com/CppCon/CppCon2014/tree/master/Presentations/Hourglass%20Interfaces%20for%20C%2B%2B%20APIs
>>>>
>>>> Dirk
>>>>
>>>> --
>>>> https://dirk.eddelbuettel.com | @eddelbuettel | edd using debian.org