The problem here is that Mac Ports installs a very old version of Octave. Installing the latest version (3.6.4) from source seems to resolve the issue. At least .O$version() works!
Installing Octave from source under MacOS takes some work due to many dependencies, and the need for work-arounds for Apple changes and deprecated features. See, for example: http://wiki.octave.org/Octave_for_Mac On Thu, Oct 10, 2013 at 1:01 AM, Dominick Samperi <djsamp...@gmail.com>wrote: > It appears that there is some conflict between Rcpp and Octave under > Mac OS X that doesn't depend on the design of RcppOctave. Just > drop the files strtest.cpp and Makevars (attached) into Rcpp/src and > run R CMD INSTALL Rcpp. This leads to a memory error. The file > strtest.cpp was stripped out of rcpp_octave.cpp, but it does not > use RcppOctave or Rcpp (it is just a trivial Octave client). > > Since the problem is OS-dependent, it might have something do to > with static initializers in the Octave string_vector class, or perhaps > there > is a MacOS-specific conflict with std::string. > > > > On Wed, Oct 9, 2013 at 4:21 AM, Renaud Gaujoux < > ren...@mancala.cbio.uct.ac.za> wrote: > >> You are a resourceful person Dominick! :D >> I was not thinking in going Mac for now, because I can't test anything, >> but it will be great if we manage our way through it as well. >> >> 1. In src/modules/Makefile.in, the '-F' flag (for framework) is not >>> recognized by mkoctfile, so I added this temporary work-around: >>> >>> #R_LDFLAGS = @R_LDFLAGS@ >>> R_LDFLAGS = -L/Library/Frameworks/R.framework/Libraries -lR >>> >> >> One can probably test for Mac in configure.in and tweak the R_LDFLAGS >> for this platform only. >> >>> >>> 2. Parsing the man files o_whatever.Rd fails (attempt to >>> free an unallocated pointer), so I removed all of these >>> man pages for now (the failure occurs in >>> <R>/src/library/tools/R/Rd.R, function .build_Rd_db(), >>> where .fetch_Rd_object is applied to each Rd file). >>> >> >> The o_*.Rd files document more R-friendly wrappers to octave functions. >> They contain \Sexp statements that retrieve Octave help files of the >> associated function via RcppOctave o_help function: >> >> \Sexpr[results=rd,stage=render]{RcppOctave::o_help(<octave_function_name>, >> format='rd')} >> >> For packages that contain such expressions in man pages, R CMD build also >> generate the manual pdf, by installing the package in a temp directory and >> evaluating the code in all \Sexpr statements. On Windows, R CMD INSTALL >> --build also renders the man pages. >> So the issue will probably solves away when the package loads properly. >> >> For quick testing compilation and load on Windows, I run R CMD INSTALL >> directly on the package source directory with flag --no-help. To ensure a >> fresh compilation at each run I use --preclean which runs the cleanup >> script, and removes everything, including the .o, .so, .dll, .oct files: >> >> # mkdir libtest >> R --vanilla CMD INSTALL -l libtest --no-help --preclean pkg_src_directory >> >> >>> 3. With these changes the build gets to the point where >>> the install process checks if the package can be >>> loaded, and fails with: >>> >>> ** testing if installed package can be loaded >>> sh: line 1: 55395 Abort trap: 6 >>> '/Library/Frameworks/R.framework/Resources/bin/R' --no-save --slave 2>&1 < >>> '/var/folders/fq/2th4vc9n1mq9cxv5nl9bmzkc0000gn/T//RtmpbjkEA7/filed5d471d0dd21' >>> R(55395) malloc: *** error for object 0x7fff7684d570: pointer being >>> freed was not allocated >>> *** set a breakpoint in malloc_error_break to debug >>> ERROR: loading failed >>> * removing ‘/Users/dsamperi/Library/R/3.0/library/RcppOctave’ >>> * restoring previous ‘/Users/dsamperi/Library/R/3.0/library/RcppOctave’ >>> >>> 4. If I ignore this and try to run library(RcppOctave) in R I get: >>> >>> > library(RcppOctave) >>> Loading required package: Rcpp >>> Loading required package: pkgmaker >>> Loading required package: registry >>> R(55403) malloc: *** error for object 0x7fff7684d570: pointer being >>> freed was not allocated >>> *** set a breakpoint in malloc_error_break to debug >>> Abort trap: 6 >>> >>> 5. Setting the breakpoint as instructed was not very helpful >>> as the malloc code does not have symbols and cannot be >>> traced. >>> >>> >> I will double check for bad allocations in the code, but will >> unfortunately be limited in my ability to debug this. >> >> Renaud >> >> > >
_______________________________________________ Rcpp-devel mailing list Rcpp-devel@lists.r-forge.r-project.org https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
