<div dir="ltr">The problem here is that Mac Ports installs a very old version of Octave.<div>Installing the latest version (3.6.4) from source seems to resolve the</div><div>issue. At least .O$version() works!</div>
<div><br></div><div>Installing Octave from source under MacOS takes some work due</div><div>to many dependencies, and the need for work-arounds for Apple</div><div>changes and deprecated features. See, for example:</div>

<div><a href="http://wiki.octave.org/Octave_for_Mac">http://wiki.octave.org/Octave_for_Mac</a><br></div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Oct 10, 2013 at 1:01 AM, Dominick Samperi <span dir="ltr"><<a href="mailto:djsamperi@gmail.com" target="_blank">djsamperi@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">It appears that there is some conflict between Rcpp and Octave under<div>Mac OS X that doesn't depend on the design of RcppOctave. Just</div>
<div>drop the files strtest.cpp and Makevars (attached) into Rcpp/src and</div>
<div>run R CMD INSTALL Rcpp. This leads to a memory error. The file</div><div>strtest.cpp was stripped out of rcpp_octave.cpp, but it does not</div><div>use RcppOctave or Rcpp (it is just a trivial Octave client).</div>
<div><br></div><div>Since the problem is OS-dependent, it might have something do to</div><div>with static initializers in the Octave string_vector class, or perhaps there</div><div>is a MacOS-specific conflict with std::string.</div>

<div><br></div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Oct 9, 2013 at 4:21 AM, Renaud Gaujoux <span dir="ltr"><<a href="mailto:renaud@mancala.cbio.uct.ac.za" target="_blank">renaud@mancala.cbio.uct.ac.za</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>You are a resourceful person Dominick! :D<br></div>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.<br>

<div class="gmail_extra">
<br><div class="gmail_quote"><div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>1. In src/modules/Makefile.in, the '-F' flag (for framework) is not</div>


<div>
    recognized by mkoctfile, so I added this temporary work-around:</div><div><br></div><div><div>#R_LDFLAGS = @R_LDFLAGS@</div><div>R_LDFLAGS = -L/Library/Frameworks/R.framework/Libraries -lR</div></div></div></blockquote>


<div><br></div></div><div>One can probably test for Mac in <a href="http://configure.in" target="_blank">configure.in</a> and tweak the R_LDFLAGS for this platform only.<br></div><div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">


<div dir="ltr"><div><div><br></div>
<div>2. Parsing the man files o_whatever.Rd fails (attempt to</div><div>    free an unallocated pointer), so I removed all of these</div><div>    man pages for now (the failure occurs in</div><div>
   <R>/src/library/tools/R/Rd.R, function .build_Rd_db(),</div><div>   where .fetch_Rd_object is applied to each Rd file).</div></div></div></blockquote><div><br></div></div><div>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:<br>


<br>\Sexpr[results=rd,stage=render]{RcppOctave::o_help(<octave_function_name>, format='rd')}<br><br></div><div>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.<br>


</div><div>So the issue will probably solves away when the package loads properly.<br></div><div><br>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:<br>


<br></div><div># mkdir libtest<br></div><div>R --vanilla CMD INSTALL -l libtest --no-help --preclean pkg_src_directory<br></div><div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">


<div dir="ltr"><div><div><br></div><div>3. With these changes the build gets to the point where</div>
<div>    the install process checks if the package can be</div><div>    loaded, and fails with:</div><div><br></div><div><div><div>** testing if installed package can be loaded</div></div><div>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'</div>



<div>R(55395) malloc: *** error for object 0x7fff7684d570: pointer being freed was not allocated</div><div>*** set a breakpoint in malloc_error_break to debug</div><div>ERROR: loading failed</div><div>* removing ‘/Users/dsamperi/Library/R/3.0/library/RcppOctave’</div>



<div>* restoring previous ‘/Users/dsamperi/Library/R/3.0/library/RcppOctave’</div><div><br></div><div>4. If I ignore this and try to run library(RcppOctave) in R I get:</div><div><br></div><div><div>> library(RcppOctave)</div>



<div>Loading required package: Rcpp</div><div>Loading required package: pkgmaker</div><div>Loading required package: registry</div><div>R(55403) malloc: *** error for object 0x7fff7684d570: pointer being freed was not allocated</div>



<div>*** set a breakpoint in malloc_error_break to debug</div><div>Abort trap: 6</div><div><br></div><div>5. Setting the breakpoint as instructed was not very helpful</div><div>as the malloc code does not have symbols and cannot be</div>



<div>traced.</div></div></div></div></div><div><div><div class="gmail_extra"><br></div></div></div></blockquote><div><br></div></div><div>I will double check for bad allocations in the code, but will unfortunately be limited in my ability to debug this.<span><font color="#888888"><br>


<br></font></span></div><span><font color="#888888"><div>Renaud<br></div><div> </div></font></span></div></div></div>
</blockquote></div><br></div>
</div></div></blockquote></div><br></div>