rcppmlpack / rcppmlpack2

Rcpp Interface to mlpack (version 2.1.0 and up)
GNU General Public License v2.0
24 stars 9 forks source link

Install fail - cannot find mlpack header files #21

Closed chrisvwn closed 5 years ago

chrisvwn commented 5 years ago

Hi,

I am having an issue installing rcppmlpack2 on rhel 7. The default gcc is v4.8.5 but this is not sufficient for openmp which I require. So I have installed the devtoolset-6 which I enable using the command .

The install seems to choke on the source install of rcppMLPACK. Incidentally, I am able to install rcppMLPACK manually from CRAN successfully.

It seems the rcppMLPACK source is unable to find the mlpack headers in /usr/local/include? I did find that g++6 does not by default check /usr/local/include. Is there a variable I need to set that will solve this. I have tried CFLAGS, CPLUS_FLAGS, MLPACK_CFLAGS, MLPACK_CPPFLAGS. I have even tried setting gcc, g++, cpp aliases to include the library path like -I/usr/local/include. However, I am unable to get the build/install to work. Any help appreciated.

My sessionInfo:

> sessionInfo()
R version 3.5.1 (2018-07-02)
Platform: x86_64-redhat-linux-gnu (64-bit)
Running under: Red Hat Enterprise Linux

Matrix products: default
BLAS/LAPACK: /usr/lib64/R/lib/libRblas.so

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

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

loaded via a namespace (and not attached):
 [1] Rcpp_1.0.0        rstudioapi_0.8    magrittr_1.5      usethis_1.4.0     devtools_2.0.1    pkgload_1.0.2     R6_2.3.0          rlang_0.3.0.1     tools_3.5.1      
[10] pkCould yougbuild_1.0.2    sessioninfo_1.1.1 cli_1.0.1         withr_2.1.2       remotes_2.0.2     assertthat_0.2.0  digest_0.6.18     rprojroot_1.3-2   crayon_1.3.4     
[19] processx_3.2.0    callr_3.0.0       base64enc_0.1-3   fs_1.2.6          ps_1.2.1          curl_3.2          memoise_1.1.0     glue_1.3.0        compiler_3.5.1   
[28] desc_1.2.0        backports_1.1.2   prettyunits_1.0.2

The output from the install is below:

> devtools::install_github("rcppmlpack/rcppmlpack2")
Downloading GitHub repo rcppmlpack/rcppmlpack2@master
✔  checking for file ‘/tmp/RtmpTGbarz/remotes691f797e3951/rcppmlpack-rcppmlpack2-4af4b01/DESCRIPTION’ ...
─  preparing ‘RcppMLPACK’:
✔  checking DESCRIPTION meta-information ...
─  cleaning src
─  running ‘cleanup’
─  checking for LF line-endings in source and make files and shell scripts
─  checking for empty or unneeded directories
─  looking to see if a ‘data/datalist’ file should be added
─  building ‘RcppMLPACK_3.0.1-0.0.tar.gz’

Installing package into ‘/root/R/x86_64-pc-linux-gnu-library/3.5.1’
(as ‘lib’ is unspecified)
* installing *source* package ‘RcppMLPACK’ ...
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 for gcc... gcc
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking whether we are using the GNU C++ compiler... (cached) yes
checking whether g++ accepts -g... (cached) yes
checking whether g++ supports C++11 features by default... yes
checking for pkg-config... yes
checking for grep that handles long lines and -e... /bin/grep
checking for egrep... /bin/grep -E
checking for ANSI C header files... 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 mlpack/core.hpp usability... no
checking mlpack/core.hpp presence... no
checking for mlpack/core.hpp... no
configure: error: Cannot find MLPACK headers.
ERROR: configuration failed for package ‘RcppMLPACK’
* removing ‘/root/R/x86_64-pc-linux-gnu-library/3.5.1/RcppMLPACK’
* restoring previous ‘/root/R/x86_64-pc-linux-gnu-library/3.5.1/RcppMLPACK’
Error in i.p(...) : 
  (converted from warning) installation of package ‘/tmp/RtmpTGbarz/file691f4fd5f752/RcppMLPACK_3.0.1-0.0.tar.gz’ had non-zero exit status
eddelbuettel commented 5 years ago

Step back for a second and realize that there are TWO repos and source packages. The old RcppMLPACK (also on CRAN) and a second, newer one. If you use the second one then you must also use a corresponding (recent enough) MLPACK installation. References of success with the former mean nothing.

The error message at end of your snippet is as clear as we can make it:

configure: error: Cannot find MLPACK headers.

chrisvwn commented 5 years ago

@eddelbuettel I realize the two are different. Kindly ignore that part. I should have mentioned that I have mlpack 3.0.4 installed. What I am trying to figure out is why it cannot find the headers which are clearly under /usr/local/include/mlpack. Is it related to my gcc? Is there a way that I can help the install find the headers?

eddelbuettel commented 5 years ago

@chrisvwn Ok, same page then. On my box it is /usr/include/mlpack/ which is the other default location. We'd need to dig into the configure.log to see why/how it failed.

chrisvwn commented 5 years ago

Hmm. I tried cloning the rcppmlpack/rcppmlpack2 repo and running ./configure. Interestingly the default gcc 4.8.5 finds the mlpack headers (which I now installed to /usr/include/mlpack) and configures fine.

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 for gcc... gcc
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking whether we are using the GNU C++ compiler... (cached) yes
checking whether g++ accepts -g... (cached) yes
checking whether g++ supports C++11 features by default... no
checking whether g++ supports C++11 features with -std=c++11... yes
checking for pkg-config... yes
checking for grep that handles long lines and -e... /bin/grep
checking for egrep... /bin/grep -E
checking for ANSI C header files... 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 mlpack/core.hpp usability... yes
checking mlpack/core.hpp presence... yes
checking for mlpack/core.hpp... yes
checking for mlpack/core.hpp... (cached) yes
checking for main in -lmlpack... yes
checking whether we are using the GNU C++ compiler... (cached) yes
checking whether g++ -std=c++11 accepts -g... (cached) yes
checking whether g++ version is sufficient... yes, but without OpenMP as version 4.8.5 (Armadillo/MLPACK constraint)
checking for macOS... /usr/local/lib64/R/bin/Rscript: error while loading shared libraries: libiomp5.so: cannot open shared object file: No such file or directory
not found
configure: creating ./config.status
config.status: creating src/Makevars
configure: creating ./config.status
config.status: creating src/Makevars
config.status: creating R/inline.R

RcppMLPACK 3.0.1-1
==================

compiler:   g++ -std=c++11
cflags:          
libs:           -lmlpack 
pkgconfig:      yes

Still fails with gcc 6.3.1. I have attached the 2 config.logs. Hopefully someone can spot something?

config-gcc4.log config-gcc6.log

chrisvwn commented 5 years ago

I just perused the logs and this seems like the error gcc6 is encountering:

configure:4652: g++ -c -fopenmp -O2 -I/usr/local/include  conftest.cpp >&5
In file included from /usr/include/mlpack/core.hpp:256:0,
                 from conftest.cpp:53:
/usr/include/mlpack/prereqs.hpp:94:2: error: #error Use of C++14 mode with Boost < 1.59 is known to cause compilation problems. Instead specify the C++11 standard (-std=c++11 with gcc or clang), or upgrade Boost to 1.59 or newer.
 #error Use of C++14 mode with Boost < 1.59 is known to cause compilation \
  ^~~~~

It seems related to https://github.com/mlpack/mlpack/issues/1033

Do I need to upgrade my Boost? Or can I pass -std=c++11 to gcc during the package install?

eddelbuettel commented 5 years ago

That may be the change vector. I have Boost 1.65 now on Ubuntu 18.04, I think it was 1.62 before that.

That said, I also never had that error when we did earlier work on RcppMLPACK2.

eddelbuettel commented 5 years ago

Also, RcppMLPACK2 alreay imposes C++11, see this line.

chrisvwn commented 5 years ago

Thanks @eddelbuettel That leaves only boost. Let me install boost >= 1.59 from source. I think this will require a rebuild of armadillo and mlpack as well. Then try rcppmlpack2 again. I will come back to report.

eddelbuettel commented 5 years ago

Appreciate your patience. In case you have the ability to run Docker, our repo now has containers to

  1. test, and
  2. run

as that also made our live with Travis CI easier.

Ie the repo defines the Dockerfile, Docker Hub builds them, Travis uses the testing variant and we offer a run-time variant "just because we can". Let me know if that would help.

chrisvwn commented 5 years ago

Good news! Installing boost solved the problem. I thought I would need to rebuild armadillo and mlpack but clearly I don't fully understand how they relate - not required.

Thanks for the information about using docker. This might actually be quite useful to us. We are currently building a test machine and being able to build a docker image of the final setup would be quite helpful. I will come back to you in case we do end up going down this path.

Thanks @eddelbuettel for your speedy help. Much appreciated!