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

[Tomas Kalibera]

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