eddelbuettel / inline Goto Github PK

The (acting) inline maintainer (ie, me) occassionally gets email by people wanting better Fortran support. I don't use Fortran myself, and inline is in maintenance mode as we have newer/better tools in the Rcpp project now for its use.

But if someone wants to drive Fortran changes for inline forward, they definitely could. This has to be done the proper way with a patch ("pull request"), updates to the documentation, ideally some tests (or examples) -- and of course zero impact on existing functionality in inline.

On Windows, using R 4.x this example of trying to use PKG_LIBS

library(inline)
settings <- getPlugin("Rcpp")
settings$env$PKG_LIBS <- "-lfoo" # foo library does not exist
fx <- cxxfunction( signature(x = "integer", y = "numeric" ) , '
		return wrap( as<int>(x) * as<double>(y) ) ;
	', settings = settings, verbose = TRUE )
fx(2L, 5)

"works" when it should fail with a linker error (which it does on Debian)

Error in compileCode(f, code, language = language, verbose = verbose) :
Compilation ERROR, function(s)/method(s) not created! /usr/bin/ld: cannot find -lfoo
collect2: error: ld returned 1 exit status

Conversely, more complicated examples where someone is trying to link against a real library on Windows fail when they should work.

If I insert a --dry-run argument to R CMD SHLIB on Windows, I get

make cmd is
make -f "C:/PROGRA1/R/R-401.2/etc/x64/Makeconf" -f "C:/PROGRA1/R/R-401.2/share/make/winshlib.mk" -f "C:/Users/Stan/Documents/.R/Makevars.win" SHLIB_LDFLAGS='$(SHLIB_CXXLDFLAGS)' SHLIB_LD='$(SHLIB_CXXLD)' SHLIB="file20b469d76e48.dll" PKG_LIBS='2> file20b469d76e48.cpp.err.txt' WIN=64 TCLBIN=64 OBJECTS="file20b469d76e48.o"
make would use
"C:/RBuildTools/4.0/mingw64/bin/"g++ -std=gnu++11 -I"C:/PROGRA1/R/R-401.2/include" -DNDEBUG -I"C:/Users/Stan/Documents/R/win-library/4.0/Rcpp/include" -O2 -Wall -mfpmath=sse -msse2 -mstackrealign -c file20b469d76e48.cpp -o file20b469d76e48.o
if test "zfile20b469d76e48.o" != "z"; then
if test -e "file20b469d76e48-win.def"; then
echo "C:/RBuildTools/4.0/mingw64/bin/"g++ -std=gnu++11 -shared -s -static-libgcc -o file20b469d76e48.dll file20b469d76e48-win.def file20b469d76e48.o 2> file20b469d76e48.cpp.err.txt -L"C:/PROGRA1/R/R-401.2/bin/x64" -lR ;
"C:/RBuildTools/4.0/mingw64/bin/"g++ -std=gnu++11 -shared -s -static-libgcc -o file20b469d76e48.dll file20b469d76e48-win.def file20b469d76e48.o 2> file20b469d76e48.cpp.err.txt -L"C:/PROGRA1/R/R-401.2/bin/x64" -lR ;
else
echo EXPORTS > tmp.def;
"C:/RBuildTools/4.0/mingw64/bin/"nm file20b469d76e48.o | sed -n 's/^.* [BCDRT] / /p' | sed -e '/[.]refptr[.]/d' -e '/[.]weak[.]/d' | sed 's/[^ ][^ ]*/"&"/g' >> tmp.def;
echo "C:/RBuildTools/4.0/mingw64/bin/"g++ -std=gnu++11 -shared -s -static-libgcc -o file20b469d76e48.dll tmp.def file20b469d76e48.o 2> file20b469d76e48.cpp.err.txt -L"C:/PROGRA1/R/R-401.2/bin/x64" -lR ;
"C:/RBuildTools/4.0/mingw64/bin/"g++ -std=gnu++11 -shared -s -static-libgcc -o file20b469d76e48.dll tmp.def file20b469d76e48.o 2> file20b469d76e48.cpp.err.txt -L"C:/PROGRA1/R/R-401.2/bin/x64" -lR ;
rm -f tmp.def;
fi
fi

The PKG_LIBS='2> file20b469d76e48.cpp.err.txt' in the call to R CMD SHLIB does not look right. If I change the middle of compileCode on Windows to not write the errors to errfile by

cmd <- paste(R.home(component = "bin"), "/R CMD SHLIB ", 
    basename(libCFile), sep = "")

then I get the expected behavior

"C:/RBuildTools/4.0/mingw64/bin/"g++ -std=gnu++11 -I"C:/PROGRA1/R/R-401.2/include" -DNDEBUG -I"C:/Users/Stan/Documents/R/win-library/4.0/Rcpp/include" -O2 -Wall -mfpmath=sse -msse2 -mstackrealign -c file20b413636b83.cpp -o file20b413636b83.o
C:/RBuildTools/4.0/mingw64/bin/g++ -std=gnu++11 -shared -s -static-libgcc -o file20b413636b83.dll tmp.def file20b413636b83.o -lfoo -LC:/PROGRA1/R/R-401.2/bin/x64 -lR
C:/RBuildTools/4.0/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/8.3.0/../../../../x86_64-w64-mingw32/bin/ld.exe: cannot find -lfoo
collect2.exe: error: ld returned 1 exit status

This might be an R bug in tools:::.shlib_internal, but I think it could be avoided by compileCode invoking system2 instead of system because the system2 function has arguments for redirecting stdout and stderr to files. If anyone else is bitten by this, it can be worked around on Windows by putting the linker arguments in the LOCAL_LIBS environmental variable rather than PKG_LIBS.

Hi, I have attempted to run the first cfunction example in the inline package and it has failed. I have not attempted any of the other examples yet.

Thank you.

Package: inline
Version: 0.3.14
Date: 2015-04-11
R version 3.2.0 (GNU/Linux) & R version 3.1.3-patched (Microsoft Windows)

library("inline", lib.loc="~/R/x86_64-pc-linux-gnu-library/library")
x <- as.numeric(1:10)
n <- as.integer(10)

Not run:

A simple Fortran example - n and x: assumed-size vector

code <- "

• integer i
• do 1 i=1, n(1)
• 1 x(i) = x(i)**3
• "
  cubefn <- cfunction(signature(n="integer", x="numeric"), code, convention=".Fortran")
  file48a67a1ab38c.f:6.1:

integer i
1
Error: Non-numeric character in statement label at (1)
file48a67a1ab38c.f:6.1:

integer i
1
Error: Unclassifiable statement at (1)
file48a67a1ab38c.f:7.1:

do 1 i=1, n(1)
1
Error: Non-numeric character in statement label at (1)
file48a67a1ab38c.f:7.1:

do 1 i=1, n(1)
1
Error: Unclassifiable statement at (1)
file48a67a1ab38c.f:8.3:

1 x(i) = x(i)**3
1
Error: Non-numeric character in statement label at (1)
file48a67a1ab38c.f:8.3:

1 x(i) = x(i)*3
1
Error: Unclassifiable statement at (1)
make: ** [file48a67a1ab38c.o] Error 1

ERROR(s) during compilation: source code errors or compiler configuration errors!

Program source:
1:
2: SUBROUTINE file48a67a1ab38c ( n, x )
3: INTEGER n()
4: DOUBLE PRECISION x()
5:
6: integer i
7: do 1 i=1, n(1)
8: 1 x(i) = x(i)**3
9:
10: RETURN
11: END
12:
Error in compileCode(f, code, language, verbose) :
Compilation ERROR, function(s)/method(s) not created! file48a67a1ab38c.f:6.1:

integer i
1
Error: Non-numeric character in statement label at (1)
file48a67a1ab38c.f:6.1:

integer i
1
Error: Unclassifiable statement at (1)
file48a67a1ab38c.f:7.1:

do 1 i=1, n(1)
1
Error: Non-numeric character in statement label at (1)
file48a67a1ab38c.f:7.1:

do 1 i=1, n(1)
1
Error: Unclassifiable statement at (1)
file48a67a1ab38c.f:8.3:

1 x(i) = x(i)**3
1
Error: Non-numeric character in statement label at (1)
file48a67a1ab38c.f:8.3:

1 x(i) = x(i)*3
1
Error: Unclassifiable statement at (1)
make: ** [file48a67a1ab38c.o] Error 1
In addition: Warning message:
running command '/usr/lib/R/bin/R CMD SHLIB file48a67a1ab38c.f 2> file48a67a1ab38c.f.err.txt' had status 1

print(cubefn)
Error in print(cubefn) :
error in evaluating the argument 'x' in selecting a method for function 'print': Error: object 'cubefn' not found

In the cfunction there are cppargs/cxxargs arguments that refers to CPPFLAGS/CXXFLAGS but there is no cargs that would refer to CFLAGS. FR to add that one.

Currently there are no tests driven from tests/ either directly or via a test runner in the package but only tests relying on help page examples that do not check the output of the compiled functions.

KH emailed

Please see the problems shown on https://cran.r-project.org/web/checks/check_results_inline.html.

Please correct before 2021-05-27 to safely retain your package on CRAN.

@jranke I may need your help here as the issues, following the link above appear to end in the tests for moveDLL applied to quadfun:

Running test_utilities.R.............. 3 tests [0;32mOK [0m \
    Error in .Primitive(".C")(<pointer: (nil)>, n = as.integer(n), x = as.double(x)) :
    NULL value passed as symbol address
  Calls: <Anonymous> ... eval -> expect_identical -> fun -> quadfn -> <Anonymous>
  Execution halted

I'll start by trying to reproduce on RHub.

I frequently generate cfunctions in my mkin package by generating C code from a user specified ODE model definition which is then compiled for fast solutions with deSolve within iterative optimizations. Generally, it is fine to have the compiled code under /tmp, but when I have large knitr documents and specific chunks take a long time to complete I use knitr chunk caching and I get problems with model objects in the knitr cache not finding their compiled code any more. Therefore, I would like to store the shared objects generated by cfunctions in a user defined path, e.g. in the current working directory.

The functions readDynLib and writeDynLib from R/utilities.R would fit the bill, but they are not exported, and the former has a bug making the example code in dontrun fail, even if the functions are found by using inline:::readDynLib and inline:::writeDynLib. An alternative to fixing and exporting these functions would be to add an argument to cfunction, defining a path for the shared object.

I can get BLAS calls to work with no problem.

library(inline)
# http://www.netlib.org/lapack/explore-html/db/dc9/group__single__blas__level3_gafe51bacb54592ff5de056acabd83c260.html#gafe51bacb54592ff5de056acabd83c260
blas <- '
  double alpha=1.0;
  dgemm_("N", "N", m, n, k, &alpha, a , m, b, k, &alpha, c, m);
'
mmul   <- cfunction(signature(
                      a="double",
                      b="double",
                      c="double",
                      m="integer",
                      n="integer",
                      k="integer"
                    ),
                    blas,
                    includes = c("#include <R_ext/BLAS.h>"),
                    language = "C",
                    convention = ".C")
x <- matrix(1:6,  nrow=3, ncol=2)
y <- matrix(7:14, nrow=2, ncol=4)
z <- rep(0, 12)
ans <- mmul(x, y, z, nrow(x), ncol(y), nrow(y))$c

Which results in

> x %*% y
     [,1] [,2] [,3] [,4]
[1,]   39   49   59   69
[2,]   54   68   82   96
[3,]   69   87  105  123
> matrix(ans, nrow=3, ncol=4)
     [,1] [,2] [,3] [,4]
[1,]   39   49   59   69
[2,]   54   68   82   96
[3,]   69   87  105  123

But when I try LAPACK calls the link fails.

lapack <- '
  int i;
  i=1;
  dpotrf_("U", N, A, &i, info);
'
ichol   <- cfunction(signature(
                      N="integer",
                      A="double",
                      info="integer"
                    ),
                    lapack,
                    includes = c("#include <R_ext/Lapack.h>"),
                    language = "C",
                    libargs = "-L$(LAPACK_LIBS)",
                    convention = ".C")

# Did it work?
ichol(2, c(2, -1, 2), 0)
chol(matrix(c(2,-1,-1,2), nrow=2))

Which fails with:

Error in dyn.load(libLFile) : 
  unable to load shared object '/tmp/RtmpUxjlYM/file2243e3af0ed3d.so':
  /tmp/RtmpUxjlYM/file2243e3af0ed3d.so: undefined symbol: dpotrf_

What am I leaving out to get the LAPACK to link properly?

In R 3.4.3

library("inline")
readDynLib()

Error in readDynLib() : could not find function "readDynLib"

packageVersion("inline")

[1] ‘0.3.14’

defining the function to be the same as in this repo seems to solve it. Is utilities.R not fully linked from the package?

I try to run this code in my computer

suppressMessages(library(Rcpp))
suppressMessages(library(inline))
cat("===Doubles\n")
foo <- '
double d = Rcpp::as<double>(x);
std::cout << "Returning twice the value of " << d << " : ";
return(Rcpp::wrap( 2*d ) );
'
funx <- cfunction(signature(x="numeric"), foo, Rcpp=TRUE, verbose=FALSE)

But an error appears

Loading required namespace: TRUE
Failed with error:  ‘there is no package called ‘TRUE’’
Error in cfunction(signature(x = "numeric"), foo, Rcpp = TRUE, verbose = FALSE) : 
  Rcpp cannot be loaded, install it or use the default Rcpp=FALSE

R version:

> sessionInfo()
R version 3.2.1 (2015-06-18)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: Ubuntu 14.04.2 LTS

locale:
 [1] LC_CTYPE=en_US.UTF-8       LC_NUMERIC=C               LC_TIME=en_GB.UTF-8        LC_COLLATE=en_US.UTF-8     LC_MONETARY=en_GB.UTF-8    LC_MESSAGES=en_US.UTF-8   
 [7] LC_PAPER=en_GB.UTF-8       LC_NAME=C                  LC_ADDRESS=C               LC_TELEPHONE=C             LC_MEASUREMENT=en_GB.UTF-8 LC_IDENTIFICATION=C       

attached base packages:
[1] stats     graphics  grDevices utils     datasets  methods   base     

other attached packages:
[1] Rcpp_0.11.6   inline_0.3.14