[R-pkg-devel] Another DLL requires the use of native symbols thread

Dirk Eddelbuettel edd @end|ng |rom deb|@n@org
Sat Mar 25 14:19:38 CET 2023


On 25 March 2023 at 13:01, Shawn Way wrote:
| Sorry to kind of repeat this but I really didn't understand the issues with the prior thread and how it relates to my issue.
| 
| I'm getting the error message in
| 
|     B_T <- BT(Temp)
|     Error in BT(Temp) : DLL requires the use of native symbols
|     Execution halted
| 
| And frankly, I have no idea what this means.  The function call is pretty simple and meets the requirement of .Fortran
| 
| res <- .Fortran('BT', as.double(Temp), as.double(y), as.integer(icode))
                  ^^^^

'BT' is a character (as opposed to a symbol) yet ...

| and the following matches the R-ext's method for using registration:
| 
| extern void F77_NAME(bt)(double *T, double *B, int *icode);
| 
| void R_init_IAPWS95(DllInfo *dll)
| {
|   R_registerRoutines(dll, NULL, NULL, FortranEntries, NULL);
|   R_useDynamicSymbols(dll, FALSE);
|   R_forceSymbols(dll, TRUE);

... this line ask R to enfore a (registered, the two preceeding lines) symbol.

This is a conflict, and R-devel now flags it as error (when a 'switch it on'
environment variable is set). Sometimes such changes become mandatory.

In any event it is something you can change. Either stick with the character
variable identifying your routine (and likely suffer epsilon-size slowdowns
for the lookup) and go through with calling the routine by its registered
symbol.  I do not interface much with .Fortran() and was under the impression
that its use is (strongly !!) discouraged (as is .C()) given that using
.Call() from R is so much more efficient (so you'd write a C(++) wrapper to
receive arguments and then have the C(++) wrapper call your Fortran routine.
There are prior threads about the mechanics of that in the list archive.

Hth,  Dirk

-- 
dirk.eddelbuettel.com | @eddelbuettel | edd using debian.org



More information about the R-package-devel mailing list