search

oracle / fastr

A high-performance implementation of the R programming language, built on GraalVM.
Other
627 stars 64 forks source link

Support for copula packages #135

Open davidpham87 opened 4 years ago

davidpham87 commented 4 years ago

Hello,

I am trying to install the copula package on ubuntu 18.04 with graalvm 20. I have the following error when trying to install the dependency mvtnorm

"/usr/lib/jvm/graalvm-ce-java11-20.0.0/languages/R/bin/f2c-wrapper" "/usr/lib/jvm/graalvm-ce-java11-20.0.0/languages/R/bin/safe-forward-gfortran" -fno-optimize-sibling-calls  -fpic  -O2  -c tvpack.f -o tvpack.o
Running f2c transformation, the log will be in ./tvpack.f2c.log
./tvpack.c:201:12: error: conflicting types for 'tvtmfn_'
doublereal tvtmfn_(doublereal *x)
           ^
./tvpack.c:90:33: note: previous declaration is here
    extern /* Subroutine */ int tvtmfn_();
                                ^
./tvpack.c:312:12: error: conflicting types for 'adonet_'
doublereal adonet_(D_fp f, doublereal *a, doublereal *b, doublereal *tol)
           ^
./tvpack.c:88:35: note: previous declaration is here
            doublereal *, doublereal *), adonet_(U_fp, doublereal *,

Should I contact the maintainer of the mvtnorm package or is this something we can solve?

steve-s commented 4 years ago

Hello,

this looks like a compilation issue.

By default we compile packages using the GraalVM LLVM Toolchain. If I simplify this, GraalVM LLVM Toolchain is a thin wrapper around clang and other tools, which makes sure that LLVM bitcode is embedded in the produced artifacts.

You can change the compiler configuration in $GRAALVM_HOME/jre/languages/R/etc/Makeconf, when I changed that to use my system gcc or system clang (not the one distributed as part of GraalVM LLVM Toolchain), it compiles fine. We will take a look at what's behind this issue. For the time being you can switch to gcc by either manually editing the configuration file or by running fastr.setToolchain("native") (fastr.setToolchain("llvm") reverts this back).

Edit: it is actually probably F2C transformation issue. We use F2C in the "llvm" mode, because there is no FORTRAN front-end for LLVM yet. The resolution is the same though: use fastr.setToolchain("native").

steve-s commented 4 years ago

Note that if you compile the packages with gcc, you won't be able to run them using the LLVM back-end (--R.BackEnd=llvm).

davidpham87 commented 4 years ago

So it can start to install the package, but it takes a overly long time to install it (like more than half an hour), compared to a few seconds in R. Would you know why?

mik3hall commented 4 years ago

Since my issue was mentioned on this I looked at it out of curiosity. It appears in this case to be the same mvtnorm package as the other issue indicated in the prior comment... https://github.com/oracle/fastr/issues/140

To me it seemed to be the problem mentioned at the end of section 6, P. 17, in the f2c pdf. https://www.netlib.org/f2c/f2c.pdf

The rules of Fortran 77 apparently permit a situation in which f 2c declares a function to be of type int, then defines it to be of another type, as illustrated by the first example in §7.

Sounded to me like this...

./tvpack.c:90:33: error: conflicting types for 'tvtmfn' extern / Subroutine / int tvtmfn();

Solutions suggested are to generate function prototypes with f2c -P. I tried that but it still had errors. Or, split out the mistyped subroutines using fsplit. That command doesn't look to be readily available anymore. I found 3rd party source, but building it and figuring out how to incorporate it into f2c-wrapper was seeming too involved for me to suggest.

mik3hall commented 4 years ago

I looked at this a little more closely and seem to have something that works although it is still sort of awkward. What was needed was two runs of f2c. The first generates the necessary prototypes. This goes to a .P file. You then run f2c again this time including the *.P file. Something like this in f2c-wrapper...

echo "Running f2c transformation, the log will be in ${log_file}" echo "including -P" .# "$F2C" "${source_file}" "-d${target_dir}" > "$log_file" 2>&1 "$F2C" "-P!c" "${source_file}" > "$log_file" 2>&1 echo "Re-doing f2c with prototypes" log Running: "${source_file}" "./${target_file_no_ext}.P" "-d${target_dir}" > "log_file" 2>&1 "$F2C" "${source_file}" "./${target_file_no_ext}.P" "-d${target_dir}" > "$log_file" 2>&1

Getting the below. I don't know if you would want to do this every time. It might cause unexpected problems with other packages. You could maybe have some option where the user could select a 'prototype' version of f2c-wrapper, f2c-wrapperP? Doing this on type errors like for this issue. Although that would not work nicely with the automatic switch to native gfortran on errors mentioned.

Anyhow, the run with the above changes...

install.packages("mvtnorm",quiet=FALSE,verbose=TRUE,keep_output=TRUE) Installing package into ‘/Users/mjh/Documents/R/fastr’ (as ‘lib’ is unspecified) system (cmd0): /Users/mjh/HalfPipe/HalfPipe_jpkg/outFastR/FastRGraalHPS.app/Contents/runtime/Contents/Home/languages/R/bin/R CMD INSTALL Content type 'application/octet-stream' length 159539 bytes (155 KB) foundpkgs: mvtnorm, /var/folders/dh/91wmrk0n6lzfmr4tjhjmcfp40000gn/T/RtmpmvCGYb/downloaded_packages/mvtnorm_1.0-8.tar.gz files: /var/folders/dh/91wmrk0n6lzfmr4tjhjmcfp40000gn/T/RtmpmvCGYb/downloaded_packages/mvtnorm_1.0-8.tar.gz