renozao / RcppOctave

Seamless Interface to Octave -- and Matlab code
18 stars 9 forks source link

Build on mac os x #1

Open ghost opened 10 years ago

ghost commented 10 years ago

The build seems to assume installation of octave by home-brew because, the configure file says, it "works out of box."

It no longer works out of box; this may be related to flux in the home-brew fortran compiler. In addition, many of the octave suggested extensions (e.g., hdf5) are either currently missing from home-brew, or have compilation issues (e.g., openblas).

I've tried octave from home-brew, building octave myself, and the binary download. The only variant that works consistently and has the ordinary extensions is the binary download.

Even when octave is installed successfully, by home-brew or the binary (and if necessary directed to the binary home by configure directives), RcppOctave fails to install because it looks for liboctinterp.so, when both home-brew and the binary install only liboctinterp.dylib.

I suggest adjusting RcppOctave's build requirements so it looks for octave in multiple locations, including the current home-brew, build-from-source into /usr/local/, and works with the .dylib.

Here's the furthest I could get with compilation:

installing to /Library/Frameworks/R.framework/Versions/3.1/Resources/library/RcppOctave/libs * R * demo * exec * inst * preparing package for lazy loading * help Error : /private/var/folders/s1/_v14lsc56tv44hm304m07vn40000gq/T/RtmpWBGJlA/R.INSTALL15e583ce00d60/RcppOctave/man/o_addpath.Rd:41: .onLoad failed in loadNamespace() for 'RcppOctave', details: call: FUN(c("/usr/local/octave/3.8.0/lib/octave/3.8.0/liboctinterp.so", error: unable to load shared object '/usr/local/octave/3.8.0/lib/octave/3.8.0/liboctinterp.so': dlopen(/usr/local/octave/3.8.0/lib/octave/3.8.0/liboctinterp.so, 6): image not found ERROR: installing Rd objects failed for package ‘RcppOctave’

renozao commented 10 years ago

This is possibly solved by commit ca8a4af Can you please test:

devtools::install_github('renozao/RcppOctave', ref = 'develop', quick = TRUE)
ghost commented 10 years ago

Thanks for getting back to me so quickly. Yes, I did try to post a bug about this, but then I found someone had had a similar issue so I contacted him.

Compiler incompatibilities are possible, but I wouldn't make them the prime suspect. Compiler dissonance is inevitable with mac os x, but i haven't had issues before when using libraries built using other compilers. Then again, I've never seen a package that fought so hard against getting built as octave, and I was never able to build it without using homebrew.

Anyway, R and Rcpp on my system were built with a different compiler and toolchain than Octave. So that may be playing a role. But, like I said, I haven't seen this before using a compiler to link to libraries built with other packages.

What I have seen a lot of are dynamic linking issue, where a library gets found at at compile time, but at run time it isn't found at all or an incompatible build of it is found. This happens on mac because if you install the gnu toolchain you end up with multiple versions of a lot of libraries. And if you use a package manager like homebrew, the gcc libraries are tied to minor version. For example, I had to recompile R entirely when homebrew updated gcc 4.9.0 to 4.9.1, because it broke the links to the 4.9.0 libraries.

Anyway, the modifications you made do solve the .so vs. dylib problem, getting me to the Symbol not found issue. This is the last bit of the output installing your latest dev build from github:

/usr/local/bin/g++-4.9 -I/Library/Frameworks/R.framework/Resources/include -DNDEBUG "/Library/Frameworks/R.framework/Resources/bin/Rscript" -e "Rcpp:::CxxFlags()" -I/usr/local/Cellar/octave/3.8.1/include/octave-3.8.1/octave/.. -I/usr/local/Cellar/octave/3.8.1/include/octave-3.8.1/octave -I/usr/local/Cellar/octave/3.8.1/include -DOCT_POST_3_4_0=1 -I/usr/local/Intel/include -I/usr/local/Intel/include/intel64/lp64 -I/usr/local/include/freetype2 -I/usr/X11/include -I/usr/local/include -I/usr/include -fopenmp -I"/Library/Frameworks/R.framework/Versions/3.1/Resources/library/Rcpp/include"
-fPIC -w -g0 -Ofast -m64 -march=native -mtune=native -fopenmp -c rcpp_octave.cpp -o rcpp_octave.o /usr/local/bin/g++-4.9 -dynamiclib -Wl,-headerpad_max_install_names -undefined dynamic_lookup -single_module -multiply_defined suppress -L/usr/local/lib/gcc/x86_64-apple-darwin13.3.0/4.9.1 -L/usr/local/lib/ -L/usr/lib -fopenmp -L/usr/local/Intel/lib -liomp5 -lmkl_core -lmkl_intel_lp64 -lmkl_intel_thread -o RcppOctave.so conversion.o rcpp_octave.o -L/usr/local/Cellar/octave/3.8.1/lib/octave/3.8.1 -L/usr/local/Cellar/octave/3.8.1/lib -loctinterp -loctave -F/Library/Frameworks/R.framework/.. -framework R -Wl,-framework -Wl,CoreFoundation installing to /Library/Frameworks/R.framework/Versions/3.1/Resources/library/RcppOctave/libs * R * exec * inst * tests * preparing package for lazy loading * help Error : /private/var/folders/s1/_v14lsc56tv44hm304m07vn40000gq/T/RtmpFumzGZ/devtools177727e9c2af7/RcppOctave-develop/man/o_addpath.Rd:41: .onLoad failed in loadNamespace() for 'RcppOctave', details: call: dyn.load(file, DLLpath = DLLpath, ...) error: unable to load shared object '/Library/Frameworks/R.framework/Versions/3.1/Resources/library/RcppOctave/libs/RcppOctave.so':

dlopen(/Library/Frameworks/R.framework/Versions/3.1/Resources/library/RcppOctave/libs/RcppOctave.so, 6): Symbol not found: __ZNK5ArrayISsE17resize_fill_valueEv Referenced from: /Library/Frameworks/R.framework/Versions/3.1/Resources/library/RcppOctave/libs/RcppOctave.so Expected in: flat namespace in /Library/Frameworks/R.framework/Versions/3.1/Resources/library/RcppOctave/libs/RcppOctave.so ERROR: installing Rd objects failed for package 'RcppOctave'

renozao commented 10 years ago

This is yet another error though. Can you please post the log of the configuration step as well? Thank you

ghost commented 10 years ago

Just updating this ---

As of today, with some changes by Renaud, RcppOctave no longer has the dylib/so problem on Mac OS.

I have gotten it to compile and run quite well when both R and Octave are made with the same toolchain. I've tested successfully with (a) the CRAN build of R and homebrew package installation of Octave, and (b) R and octave both built by hand using gcc 4.9. I was not able to get RcppOctave running when they were built with different toolchains, but I have not tested it with the latest revision.