The primary goal is to use DiffBind (a R package) to analyze my ChIPseq data.
(I found another post which might be relevant to my issue, and tried to extract the solution from it, but I guess the content was too "advanced" for me... )
Following the suggestion that I might need to update my DiffBind
I tried to install a new version of it.
By the checking the dependency of DiffBind I guess that the previous installation automatically install an old version of DiffBind because my R did not meet the requirement of current version of DiffBind.
But I was using the R under the root directory, for which I could not do much about it. So I decided install a newer version of R under my own directory. and I managed to do that.
Then I tried to install the current version of DiffBind, I got the error
ERROR: compilation failed for package ‘RcppArmadillo’
It turned out the dependency lib "RcppArmadillo" require a more up-to-date compiler, again, I was using the gcc compiler under the root directory, so I install a new version of gcc under my own directory.
$ gcc --version
gcc (GCC) 6.1.0
Copyright (C) 2016 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$ which gcc
/$HOME/Programme/gcc-6.1.0/bin//gcc
After that I tried to install the DiffBind (RcppArmadillo) again, but met another error:
* installing *source* package ‘RcppArmadillo’ ...
** package 'RcppArmadillo' successfully unpacked and MD5 sums checked
checking whether the C++ compiler works... yes
checking for C++ compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C++ compiler... yes
checking whether g++ accepts -g... yes
checking how to run the C++ preprocessor... g++ -E
checking whether we are using the GNU C++ compiler... (cached) yes
checking whether g++ accepts -g... (cached) yes
checking whether g++ version is sufficient... (6.1.0) yes
checking LAPACK_LIBS... fallback LAPACK from R 3.3.0 or later used
configure: creating ./config.status
config.status: creating inst/include/RcppArmadilloLapack.h
** libs
g++ -I/$HOME/Programme/R-3.3.1/lib64/R/include -DNDEBUG -I//$HOME/Programme/zlib-1.2.11/include -I//$HOME/Programme/bzip2-1.0.6/include -I//$HOME/Programme/xz-5.2.3/include -I//$HOME/Programme/pcre-8.40/include -I//$HOME/Programme/curl-7.52.1/include -I"/$HOME/Programme/R-3.3.1/lib64/R/library/Rcpp/include" -I../inst/include -fpic -g -O2 -c RcppArmadillo.cpp -o RcppArmadillo.o
g++ -I/$HOME/Programme/R-3.3.1/lib64/R/include -DNDEBUG -I//$HOME/Programme/zlib-1.2.11/include -I//$HOME/Programme/bzip2-1.0.6/include -I//$HOME/Programme/xz-5.2.3/include -I//$HOME/Programme/pcre-8.40/include -I//$HOME/Programme/curl-7.52.1/include -I"/$HOME/Programme/R-3.3.1/lib64/R/library/Rcpp/include" -I../inst/include -fpic -g -O2 -c RcppExports.cpp -o RcppExports.o
g++ -I/$HOME/Programme/R-3.3.1/lib64/R/include -DNDEBUG -I//$HOME/Programme/zlib-1.2.11/include -I//$HOME/Programme/bzip2-1.0.6/include -I//$HOME/Programme/xz-5.2.3/include -I//$HOME/Programme/pcre-8.40/include -I//$HOME/Programme/curl-7.52.1/include -I"/$HOME/Programme/R-3.3.1/lib64/R/library/Rcpp/include" -I../inst/include -fpic -g -O2 -c fastLm.cpp -o fastLm.o
g++ -shared -L/$HOME/Programme/R-3.3.1/lib64/R/lib -L//$HOME/Programme/zlib-1.2.11/lib -L//$HOME/Programme/bzip2-1.0.6/lib -L//$HOME/Programme/xz-5.2.3/lib -L//$HOME/Programme/pcre-8.40/lib -L//$HOME/Programme/curl-7.52.1/lib -o RcppArmadillo.so RcppArmadillo.o RcppExports.o fastLm.o -L/$HOME/Programme/R-3.3.1/lib64/R/lib -lRlapack -L/$HOME/Programme/R-3.3.1/lib64/R/lib -lRblas -lgfortran -lm -L/$HOME/Programme/R-3.3.1/lib64/R/lib -lR
/usr/bin/ld: cannot find -lgfortran
collect2: error: ld returned 1 exit status**
it turned out that gfortran could not be found.
but when I checked existence of gfortran it exist:
$ which gfortran
/usr/bin/gfortran
$ gfortran --version
GNU Fortran (GCC) 4.4.7 20120313 (Red Hat 4.4.7-17)
Copyright (C) 2010 Free Software Foundation, Inc.
GNU Fortran comes with NO WARRANTY, to the extent permitted by law.
You may redistribute copies of GNU Fortran
under the terms of the GNU General Public License.
For more information about these matters, see the file named COPYING
So I assumed that gcc could not find gfortran, which is under the root directory.
how could I solve the problem?
Or could it be possible that the mismatch between the gcc and gfortran is the problem? if that is the case, what could be done to circumvent it?
My R version:
> sessionInfo()
R version 3.3.1 (2016-06-21)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: Red Hat Enterprise Linux Server release 6.7 (Santiago)
locale:
[1] LC_CTYPE=ja_JP.UTF-8 LC_NUMERIC=C
[3] LC_TIME=ja_JP.UTF-8 LC_COLLATE=ja_JP.UTF-8
[5] LC_MONETARY=ja_JP.UTF-8 LC_MESSAGES=ja_JP.UTF-8
[7] LC_PAPER=ja_JP.UTF-8 LC_NAME=C
[9] LC_ADDRESS=C LC_TELEPHONE=C
[11] LC_MEASUREMENT=ja_JP.UTF-8 LC_IDENTIFICATION=C
attached base packages:
[1] stats graphics grDevices utils datasets methods base
I think the issue mentioned here has been solved.
As VladimirF mentioned in the comments, when I installed the new version of gcc, I did not enable the Fortran, which is not a default setting, so the gfortran was not installed in my previous attempts.
I deleted my previous Gcc, and re compiled it as follows:
tar -xvf gcc-6.1.0.tar.gz
cd gcc-6.1.0
./contrib/download_prerequisites
mkdir build
cd build
../configure --prefix=$HOME/Programme/gcc-6.1.0 --enable-languages=c,c++,fortran --disable-multilib
make -j 8
make install
set path for new gcc and lib
it worked!
Related
I have been unable to install the R package stringi on my Macbook Pro (running MacOS Monterey) with the new M1 & arm64 architecture. There are a number of posts on SO describing similar problems, but the error message I'm receiving is something I haven't seen before.
When I run install.packages("stringi") in RStudio, I receive the following error message:
stri_brkiter.cpp:60:9: error: use of undeclared identifier
'isNull'
if (isNull(opts_brkiter)) {
^
I'm guessing there is some kind of compiler mismatch going on here - there shouldn't be 'undeclared identifier' errors coming from a CRAN package. I'm not sure how to fix the problem, though, and I wasn't able to find any examples online of others getting a similar message. I've seen a lot of similar errors online, but the fixes for those haven't helped me get around this isNull() error.
Note: The lines above are just the error portion of the message output. See below for full error text.
> install.packages("stringi")
Installing package into ‘/Users/<username>/r_libs’
(as ‘lib’ is unspecified)
Package which is only available in source form, and may need
compilation of C/C++/Fortran: ‘stringi’
Do you want to attempt to install these from sources? (Yes/no/cancel) yes
installing the source package ‘stringi’
Content type 'application/x-gzip' length 7578882 bytes (7.2 MB)
==================================================
downloaded 7.2 MB
* installing *source* package ‘stringi’ ...
** package ‘stringi’ successfully unpacked and MD5 sums checked
** using staged installation
checking for R_HOME... /Library/Frameworks/R.framework/Resources
checking for R... /Library/Frameworks/R.framework/Resources/bin/R
checking for endianness... little
checking for R >= 3.1.0 for C++11 use... yes
checking for R < 3.4.0 for CXX1X flag use... no
checking for cat... /bin/cat
checking for local ICUDT_DIR... icu69/data
checking for gcc... clang -arch arm64
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether clang -arch arm64 accepts -g... yes
checking for clang -arch arm64 option to accept ISO C89... none needed
checking how to run the C preprocessor... clang -arch arm64 -E
checking for grep that handles long lines and -e... /usr/bin/grep
checking for egrep... /usr/bin/grep -E
checking for ANSI C header files... rm: conftest.dSYM: is a directory
rm: conftest.dSYM: is a directory
yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking elf.h usability... no
checking elf.h presence... no
checking for elf.h... no
checking whether we are using the GNU C++ compiler... yes
checking whether clang++ -arch arm64 -std=gnu++11 accepts -g... yes
checking whether the C++ compiler supports the long long type... yes
checking whether the compiler implements namespaces... yes
checking whether the compiler supports Standard Template Library... yes
checking whether std::map is available... yes
checking for pkg-config... /opt/homebrew/bin/pkg-config
checking with pkg-config for the system ICU4C... 70.1
checking for ICU4C >= 55... yes
checking for additional required CPPFLAGS, LDFLAGS, and LIBS... done
checking whether an ICU4C-based project can be built... yes
checking programmatically for sufficient U_ICU_VERSION_MAJOR_NUM... yes
checking programmatically if U_CHARSET_IS_UTF8 is defined and set... yes
checking the capabilities of the ICU data library (ucnv, uloc, utrans)... yes
checking the capabilities of the ICU data library (ucol)... yes
configure: creating ./config.status
config.status: creating src/Makevars
config.status: creating src/uconfig_local.h
config.status: creating src/install.libs.R
*** stringi configure summary:
ICU_FOUND=1
STRINGI_CXXSTD=CXX_STD=CXX11
STRINGI_CFLAGS= -fPIC
STRINGI_CPPFLAGS=-I. -I/opt/homebrew/Cellar/icu4c/70.1/include -UDEBUG -DNDEBUG
STRINGI_CXXFLAGS= -fPIC
STRINGI_LDFLAGS=-L/opt/homebrew/Cellar/icu4c/70.1/lib
STRINGI_LIBS=-licui18n -licuuc -licudata
*** Compiler settings used:
CC=clang -arch arm64
LD=clang++ -arch arm64 -std=gnu++14
CFLAGS=-falign-functions=64 -Wall -g -O2 -fPIC
CPPFLAGS=-I/opt/R/arm64/include -UDEBUG -DNDEBUG
CXX=clang++ -arch arm64 -std=gnu++11
CXXFLAGS=-falign-functions=64 -Wall -g -O2 -fPIC
LDFLAGS=
LIBS=
** libs
clang++ -arch arm64 -std=gnu++11 -I"/Library/Frameworks/R.framework/Resources/include" -DNDEBUG -I. -I/opt/homebrew/Cellar/icu4c/70.1/include -UDEBUG -DNDEBUG -I/opt/R/arm64/include -fPIC -fPIC -falign-functions=64 -Wall -g -O2 -c stri_brkiter.cpp -o stri_brkiter.o
stri_brkiter.cpp:60:9: error: use of undeclared identifier
'isNull'
if (isNull(opts_brkiter)) {
^
stri_brkiter.cpp:130:9: error: use of undeclared identifier
'isNull'
if (isNull(opts_brkiter)) {
^
stri_brkiter.cpp:171:9: error: use of undeclared identifier
'isNull'
if (isNull(opts_brkiter)) {
^
3 errors generated.
make: *** [stri_brkiter.o] Error 1
ERROR: compilation failed for package ‘stringi’
* removing ‘/Users/<username>/r_libs/stringi’
* restoring previous ‘/Users/<username>/r_libs/stringi’
The downloaded source packages are in
‘/private/var/folders/qc/whkk090506v2qjy698yf25m80000gq/T/RtmpvLUDID/downloaded_packages’
Warning message:
In install.packages("stringi") :
installation of package ‘stringi’ had non-zero exit status
I've tried installing stringi both in R Studio and on the command line, which some SO posts suggested may be more effective, but I receive the same errors via both methods.
Initially, the compiler was unable to find the ICU4C library (which also prevented me from installing stringi), but I was able to point pkg-config to the library by running brew link icu4c --force and that resolved it.
Other commands I've tried (that did NOT fix it):
install.packages('stringi', configure.args='--disable-cxx11')
install.packages("stringi", configure.args = "--with-extra-cxxflags='--std=c++11'")
Fully removing my Makevars file didn't resolve the issue.
I've checked many of the major/popular related questions on SO & Github (including this, this, this, this, this etc). I think I've reached the edge of my understanding of this stuff, though.
My admittedly non-expert assumption is that this has to do with the compilers I've downloaded, the M1 architecture workarounds I've done, and/or my Makevars file, as I've installed stringi on previous (older) Macbooks before without any issue.
System info:
OS: Mac OS Monterey (v 12.2) w/ an Apple M1 Max chip
R: R version 4.2.0
RStudio: RStudio version 1.4.1717
Xcode: Xcode version 13.3.1
Installed gcc/gfortran and other libraries using Homebrew & added download location to $PATH
My Makevars file:
This file was built based on advice from here, here, here, and here.
CC=/opt/homebrew/bin/gcc-11
CXX=/opt/homebrew/bin/g++-11
FC=/opt/homebrew/bin/gfortran-11
F77=/opt/homebrew/bin/gfortran-11
FLIBS=-L/opt/homebrew/opt/gfortran/lib -lgfortran -lquadmath -lm
CFLAGS=-I/opt/homebrew/include
CXXFLAGS=-O3 -Wall -pipe -Wno-unused -pedantic
CXX11FLAGS=-O3 -Wall -pipe -Wno-unused -pedantic
Does this error look familiar to anyone, or does anyone have suggestions of what I could do next to fix this? I've tried a lot of workarounds so I apologize if I've left anything out, please let me know if any other information could be useful!
Thanks!
For those returning with this same problem, it seems stringi fails to build specifically under R v.4.2.* (see here and here). Downgrading to R v.4.1.1 was sufficient to fix this on my machine, with session info below.
Prior to downgrade:
platform x86_64-apple-darwin17.0
arch x86_64
os darwin17.0
system x86_64, darwin17.0
status
major 4
minor 2.1
year 2022
month 06
day 23
svn rev 82513
language R
version.string R version 4.2.1 (2022-06-23)
nickname Funny-Looking Kid
After downgrade:
platform x86_64-apple-darwin17.0
arch x86_64
os darwin17.0
system x86_64, darwin17.0
status
major 4
minor 1.1
year 2021
month 08
day 10
svn rev 80725
language R
version.string R version 4.1.1 (2021-08-10)
nickname Kick Things
Unless you absolutely need to have source compiled version, there is a binary arm version at the moment. (Obviously people in the future will need to change the version numbers)
install.packages("https://cran.r-project.org/bin/macosx/big-sur-arm64/contrib/4.1/stringi_1.7.6.tgz",
repos = NULL, type = .Platform$pkgType)
I'm wondering if the default repository for Rstudio was not complete in this regard at the point you tried this?
I am trying to install RcppArmadillo using sparkR shell in AWS EMR version 5.29.
Here is my sessionInfo() -
R version 3.4.1 (2017-06-30)
Platform: x86_64-redhat-linux-gnu (64-bit)
Running under: Amazon Linux AMI 2018.03
Matrix products: default
BLAS/LAPACK: /usr/lib64/R/lib/libRblas.so
locale:
[1] LC_CTYPE=en_US.UTF-8 LC_NUMERIC=C
[3] LC_TIME=en_US.UTF-8 LC_COLLATE=en_US.UTF-8
[5] LC_MONETARY=en_US.UTF-8 LC_MESSAGES=en_US.UTF-8
[7] LC_PAPER=en_US.UTF-8 LC_NAME=C
[9] LC_ADDRESS=C LC_TELEPHONE=C
[11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C
attached base packages:
[1] stats graphics grDevices utils datasets methods base
other attached packages:
[1] SparkR_2.4.4
loaded via a namespace (and not attached):
[1] compiler_3.4.1 tools_3.4.1
Here is my code to install this package -
package_path <- "/home/sma/"
install.packages('RcppArmadillo',repos = "http://cran.us.r-project.org",lib=package_path, dependencies = TRUE)
Here is the failure that I get when I execute the install.packages() statement -
SparkSession available as 'spark'.
* installing *source* package ‘RcppArmadillo’ ...
** package ‘RcppArmadillo’ successfully unpacked and MD5 sums checked
checking whether the C++ compiler works... yes
checking for C++ compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C++ compiler... yes
checking whether g++ -m64 accepts -g... yes
checking how to run the C++ preprocessor... g++ -m64 -E
checking whether we are using the GNU C++ compiler... (cached) yes
checking whether g++ -m64 accepts -g... (cached) yes
checking whether we have a suitable tempdir... /tmp
checking whether R CMD SHLIB can already compile programs using OpenMP... no
checking whether g++ version is sufficient... yes, with OpenMP as version 7.2.1
checking for macOS... no
checking LAPACK_LIBS... R-supplied partial LAPACK found
configure: WARNING: Some complex-valued LAPACK functions may not be available
checking for OpenMP... found and suitable
configure: creating ./config.status
config.status: creating inst/include/RcppArmadilloConfigGenerated.h
config.status: creating src/Makevars
** libs
g++ -m64 -std=gnu++11 -I/usr/include/R -DNDEBUG -I"/home/sma/Rcpp/include" -I/usr/local/include -I../inst/include -fopenmp -fpic -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -c RcppArmadillo.cpp -o RcppArmadillo.o
In file included from ../inst/include/RcppArmadilloForward.h:49:0,
from ../inst/include/RcppArmadillo.h:31,
from RcppArmadillo.cpp:22:
../inst/include/armadillo:70:12: fatal error: omp.h: No such file or directory
#include <omp.h>
^~~~~~~
compilation terminated.
make: *** [RcppArmadillo.o] Error 1
ERROR: compilation failed for package ‘RcppArmadillo’
* removing ‘/home/sma/RcppArmadillo’
The downloaded source packages are in
‘/mnt/tmp/RtmpQmFZ4n/downloaded_packages’
Warning messages:
1: In install.packages("RcppArmadillo", repos = "http://cran.us.r-project.org", :
installation of package ‘slam’ had non-zero exit status
2: In install.packages("RcppArmadillo", repos = "http://cran.us.r-project.org", :
installation of package ‘RcppArmadillo’ had non-zero exit status
You are running 'R version 3.4.1 (2017-06-30)' so I would suggest you pick a version of RcppArmadillo of a similar vintage. The archive directory at CRAN, sorted by date suggests that version RcppArmadillo_0.7.960.1.0 came out in on 2017-08-17, or shortly after the (ancient) R release you have here.
You could of course join in the present rather than pastm but for that I recommend the current R 4.0.3 as well as a current, as opposed to several years old, OS release.
since I updated my version of Rcpp to 0.12.11 (I tested it works for 0.12.10) I cannot build my package anymore.
Actually creating a new package called dot.test from RStudio cannot be built.
Updating dot.test documentation
Loading dot.test
Re-compiling dot.test
'/usr/lib64/R/bin/R' --no-site-file --no-environ --no-save --no-restore \
--quiet CMD INSTALL '/pxfs/data/statquant/public/dot.test' \
--library='/tmp/RtmpZARXxv/devtools_install_1ef63ab8fde6' --no-R --no-data \
--no-help --no-demo --no-inst --no-docs --no-exec --no-multiarch \
--no-test-load
* installing *source* package ‘dot.test’ ...
** libs
g++ -m64 -I/usr/include/R -DNDEBUG -I/usr/local/include -I"/lxhome/statquant/R/x86_64-redhat-linux-gnu-library/3.3/Rcpp/include" -fpic -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -c RcppExports.cpp -o RcppExports.o
RcppExports.cpp:20:46: error: ‘dot’ was not declared in this scope
{"dot.test_rcpp_hello_world", (DL_FUNC) &dot.test_rcpp_hello_world, 0},
^
R> sessionInfo()
R version 3.3.0 (2016-05-03)
Platform: x86_64-redhat-linux-gnu (64-bit)
[...]
attached base packages:
[1] stats graphics grDevices utils datasets methods base
loaded via a namespace (and not attached):
[1] tools_3.3.0
R> system('which g++')
/opt/rh/devtoolset-3/root/usr/bin/g++
R> system('g++ --version')
g++ (GCC) 4.9.2 20150212 (Red Hat 4.9.2-6)
Copyright (C) 2014 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
If that's understandable that C++ and a package name with . might be asking for problems it is not explicitly forbidden (that I know of).
There are tons of packages like data.table that have a dot in the name
My questions are then:
Did I miss an explicit rule from R-core ?
Do a . in the name implies I cannot use Rcpp::compileAttributes anymore ?
Is there a quick fix that would enable me to build and still use Rcpp>0.12.10 ?
It's a bug which Kirill reported to me the other day (in person), by now filed on GitHub ... and which should get fixed "soon".
See https://github.com/RcppCore/Rcpp/issues/721 for more and progress.
The quick fix, for now, is to use a hand-edited src/init.c until compileAttributes() gets fixed.
I am trying to install Rmpi in package in R, with intel mpi installed. First I downloaded Rmpi, and the processed by following comand:
Command line
R CMD INSTALL --configure-args="--with-mpi=/opt/intel_2015/impi/5.0.1.035/intel64/" Rmpi_0.6-5.tar.gz
But it didn't install, instead it shows the following result:
Log
* installing to library ‘/home/user/R/x86_64-pc-linux-gnu-library/3.2’
* installing *source* package ‘Rmpi’ ...
** package ‘Rmpi’ successfully unpacked and MD5 sums checked
checking for gcc... icc -std=gnu99
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether icc -std=gnu99 accepts -g... yes
checking for icc -std=gnu99 option to accept ISO C89... none needed
Trying to find mpi.h ...
Found in /opt/intel_2015/impi/5.0.1.035/intel64//include
Trying to find libmpi.so or libmpich.a ...
Found libmpi in /opt/intel_2015/impi/5.0.1.035/intel64//lib
checking for openpty in -lutil... yes
checking for main in -lpthread... yes
configure: error: Unknown type of mpi: use --with-Rmpi-type or RMPI_TYPE to specify it
ERROR: configuration failed for package ‘Rmpi’
* removing ‘/home/user/R/x86_64-pc-linux-gnu-library/3.2/Rmpi’
* restoring previous ‘/home/user/R/x86_64-pc-linux-gnu-library/3.2/Rmpi’
Then I used --with-Rmpi-type='MPI2CH' and --with-Rmpi-type='OPENMPI' Nothing worked, I know It must be the mpi type problem. But I tried everything I can find, still can't figure it out.
Architecture
Centos 6.7 final
R-3.2.3
Rmpi_0.6-5
Following is my .bashrc file of intel
source /opt/intel_2015/bin/compilervars.sh intel64
source /opt/intel_2015/impi/5.0.1.035/bin64/mpivars.sh
source /opt/intel_2015/composer_xe_2015.0.090/mkl/bin/mklvars.sh intel64
source /opt/intel_2015/bin/iccvars.sh intel64
After I tried the following command:
R CMD INSTALL --configure-args="\
--with-Rmpi-include='/opt/intel_2015/impi/5.0.1.035/intel64/include' \
--with-Rmpi-libpath='/opt/intel_2015/impi/5.0.1.035/intel64/lib' \
--with-mpi='/opt/intel_2015/impi/5.0.1.035/intel64' \
--with-Rmpi-type='OPENMPI' " Rmpi_0.6-5.tar.gz
It shows the following result, still something wrong, but promising:
* installing *source* package ‘Rmpi’ ...
** package ‘Rmpi’ successfully unpacked and MD5 sums checked
checking for openpty in -lutil... no
checking for main in -lpthread... no
configure: creating ./config.status
config.status: creating src/Makevars
** libs
icc -std=gnu99 -I/opt/R-3.2.3MKL/lib64/R/include -DNDEBUG -DPACKAGE_NAME=\"\" -DPACKAGE_TARNAME=\"\" -DPACKAGE_VERSION=\"\" -DPACKAGE_STRING=\"\" -DPACKAGE_BUGREPORT=\"\" -DPACKAGE_URL=\"\" -I/opt/intel_2015/impi/5.0.1.035/intel64/include -DMPI2 -DOPENMPI -I/usr/local/include -fpic -ip -O3 -opt-mem-layout-trans=3 -xHost -march=core-avx2 -wd188 -fp-model precise -c Rmpi.c -o Rmpi.o
icc -std=gnu99 -I/opt/R-3.2.3MKL/lib64/R/include -DNDEBUG -DPACKAGE_NAME=\"\" -DPACKAGE_TARNAME=\"\" -DPACKAGE_VERSION=\"\" -DPACKAGE_STRING=\"\" -DPACKAGE_BUGREPORT=\"\" -DPACKAGE_URL=\"\" -I/opt/intel_2015/impi/5.0.1.035/intel64/include -DMPI2 -DOPENMPI -I/usr/local/include -fpic -ip -O3 -opt-mem-layout-trans=3 -xHost -march=core-avx2 -wd188 -fp-model precise -c conversion.c -o conversion.o
icc -std=gnu99 -I/opt/R-3.2.3MKL/lib64/R/include -DNDEBUG -DPACKAGE_NAME=\"\" -DPACKAGE_TARNAME=\"\" -DPACKAGE_VERSION=\"\" -DPACKAGE_STRING=\"\" -DPACKAGE_BUGREPORT=\"\" -DPACKAGE_URL=\"\" -I/opt/intel_2015/impi/5.0.1.035/intel64/include -DMPI2 -DOPENMPI -I/usr/local/include -fpic -ip -O3 -opt-mem-layout-trans=3 -xHost -march=core-avx2 -wd188 -fp-model precise -c internal.c -o internal.o
icc -std=gnu99 -shared -L/usr/local/lib64 -o Rmpi.so Rmpi.o conversion.o internal.o -L/opt/intel_2015/impi/5.0.1.035/intel64/lib -lmpi
installing to /home/user/R/x86_64-pc-linux-gnu-library/3.2/Rmpi/libs
** R
** demo
** inst
** preparing package for lazy loading
** help
*** installing help indices
** building package indices
** testing if installed package can be loaded
* DONE (Rmpi)
Please try this one:
what I figure out is dependency error. I mean Rmpi does not work if OpenMPI was compiled to dynamically load extensions, which is nowadays the default installation. If your OpenMPI is >= 1.x (and for some installs of 1.x.x) you will need to install it from the sources disabling dlopen.
So:
Try uninstalling all of the MPI interfaces, reinstalled OpenMPI
using the "--enabled-shared --disable-dlopen" command, and Rmpi should able
to install sucessfully inside R.
R CMD INSTALL Rmpi_0.6-5.tar.gz --configure-args="--with-mpi=/usr/local/ --with-Rmpi-type=OPENMPI --enabled-shared --disable-dlopen"
I hope it work for you. but don't give up :)
I am writing an R package that has Fortran source code. In short, my problem is when I try to install the package I get the error "gfortran -m32: not found" however, I am able compile my code using gfortran -m32 when I'm not installing the package.
Detailed Version:
I have installed the newest version of R(3.1.1) along with the newest version of Rtools(31) and renamed my path variables accordingly (C:\Rtools\bin;C:\Rtools\gcc-4.6.3\bin;C:\Program Files\R\R-3.1.1\bin\x64;C:\msys;C:\Program Files (x86)\SSH Secure Shell;C:\Program Files\MiKTeX 2.9\miktex\bin).
For testing purposes, I downloaded the PropClust package from CRAN which has Fortran source code.
When I type "R CMD INSTALL PropClust_1.4.tar.gz" after building it, I get the following error:
* installing *source* package 'PropClust' ...
** libs
*** arch - i386
C:/PROGRA~1/R/R-31~1.1/etc/i386/Makeconf:202: warning: overriding recipe for target `.m.o'
C:/PROGRA~1/R/R-31~1.1/etc/i386/Makeconf:195: warning: ignoring old recipe for target `.m.o'
gfortran -m32 -O3 -mtune=core2 -c PropClustParallelTrials.f90 -o PropClustParallelTrials.o
gcc -m32 -I"C:/PROGRA~1/R/R-31~1.1/include" -DNDEBUG -I"d:/RCompile/CRANpkg/extralibs64/local/include" -O3 -Wall -std=gnu99 -mtune=core2 -c minWhichMin.c -o minWhichMin.o
gfortran -m32 -shared -s -static-libgcc -o PropClust.dll tmp.def PropClustParallelTrials.o minWhichMin.o -Ld:/RCompile/CRANpkg/extralibs64/local/lib/i386 -Ld:/RCompile/CRANpkg/extralibs64/local/lib -LC:/PROGRA~1/R/R-31~1.1/bin/i386 -lR
gfortran -m32: not found
C:/PROGRA~1/R/R-31~1.1/etc/i386/Makeconf:202: warning: overriding recipe for target `.m.o'
C:/PROGRA~1/R/R-31~1.1/etc/i386/Makeconf:195: warning: ignoring old recipe for target `.m.o'
cygwin warning:
MS-DOS style path detected: C:/PROGRA~1/R/R-31~1.1/bin/i386/Rterm.exe
Preferred POSIX equivalent is: /cygdrive/c/PROGRA~1/R/R-31~1.1/bin/i386/Rterm.exe
CYGWIN environment variable option "nodosfilewarning" turns off this warning.
Consult the user's guide for more details about POSIX paths:
http://cygwin.com/cygwin-ug-net/using.html#using-pathnames
no DLL was created
ERROR: compilation failed for package 'PropClust'
* removing 'C:/Users/kamicz/Documents/IsotopeR/PropClust.Rcheck/PropClust'
Although it says "gfortran -m32: not found" I have compiled my code in the same window with the same options(gfortran -m32 -O3 -mtne=core2 -c a.f90 -o a.out) with no problems. Has anyone had this problem before? I am running Windows 7 64-bit if that matters.
I had a similar problem : R was invoking gfortran-4.8 - an unrecognized command on my system - instead of gfortran. This problem was fixed upon creating the file ~/.R/Makevars within my home directory. Here are the contents of Makevars which points to the appropriate gfortran installation:
F77 = gfortran
FC = gfortran
FLIBS = -L/usr/local/gfortran/lib