Nice. It is indeed a better solution than changing the flags and their values. The sed command did not work probably because I forgot to double the square brackets, which is necessary to correctly pass configure's first string evaluation.<div>
I will incorporate the change tomorrow.</div><div>Thanks!</div><div><br></div><div>Bests, </div><div>Renaud</div><div><br>On Wednesday, November 6, 2013, Dominick Samperi wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">The reason we have been hacking away at '-F' vs '-L' instead of<div>letting 'R CMD config' figure things out is that mkoctfile does not</div><div>know about R frameworks ('-F' is invalid). But mkoctfile does have</div>
<div>the -Wl,whatever option, which simply passes whatever down to</div><div>the linker.</div><div><br></div><div>I have attached a modified <a href="http://configure.ac" target="_blank">configure.ac</a> that uses this option</div>
<div>instead of using sed to hack the output of R CMD config --ldflags.</div>
<div><br></div></div><div><br><br><div>On Wed, Nov 6, 2013 at 10:25 AM, Dominick Samperi <span dir="ltr"><<a>djsamperi@gmail.com</a>></span> wrote:<br>
<blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hello Renaud,<div><br></div><div>So, this R technical issue (reg.finalizer) was the crux of the problem all along. Good work!</div>
<div><br></div><div>The '..' is still there and the build still fails without my hacked Makefile.in, but</div>
<div>with this change everything works (no more install memory errors).</div><div><br></div><div>The '..' in the output of R CMD config --ldflags is there for a purpose, because</div><div>the R framework is under /Library/Frameworks, and not under</div>
<div>/Library/Frameworks/R.framework. This is analogous to</div><div>-L/usr/lib/mylibs -lfoo, where /usr/lib/mylibs may contain a collection</div><div>of libraries (instead of frameworks), not just libfoo.so.</div><div>(A Mac OS framework is analogous to an R package.)</div>
<div><br></div><div>Make sure '..' is not in the path supplied to '-L' and everything should work.</div><div><br></div><div>Cheers,</div><div>Dominick</div></div><div><div><div>
<br><br><div>
On Wed, Nov 6, 2013 at 8:19 AM, Renaud Gaujoux <span dir="ltr"><<a>renaud@mancala.cbio.uct.ac.za</a>></span> wrote:<br><blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi,<br>
<br>
I made some changes available in the develop version, which should<br>
hopefully solve both issues:<br>
* octave_end is now called on exit (via reg.finalizer: see my post<br>
on r-devel <a href="https://stat.ethz.ch/pipermail/r-devel/2013-November/067912.html" target="_blank">https://stat.ethz.ch/pipermail/r-devel/2013-November/067912.html</a>)<br>
* the extra dots are removed by the sed in <a href="http://configure.ac" target="_blank">configure.ac</a>, but I think<br>
we still need to figure out why these dots are there...<br>
<br>
To test:<br>
<br>
devtools::install_github('RcppOctave', 'renozao', ref = 'develop')<br>
<br>
Thanks.<br>
<br>
Bests,<br>
Renaud<br>
<div><div><br>
On 6 November 2013 11:15, Renaud Gaujoux <<a>renaud@mancala.cbio.uct.ac.za</a>> wrote:<br>
> Couple of questions to understand what is going on:<br>
><br>
> * why does R CMD config --ldflags returns these extra '..' if they are<br>
> incorrect?<br>
> * why does the compilation work if the path is incorrect to R library is<br>
> incorrect?<br>
> * why removing the dots should solve the malloc error?<br>
><br>
><br>
><br>
> On 5 November 2013 16:38, Dominick Samperi <<a>djsamperi@gmail.com</a>> wrote:<br>
>><br>
>> R CMD config --ldflags<br>
>> yields<br>
>> -F/Library/Frameworks/R.framework/.. -framework R<br>
>><br>
>> This needs to be hacked for mkoctfile to:<br>
>> -L/Library/Frameworks/R.framework/Libraries -lR<br>
>> (no '..')<br>
>><br>
>> Applying this to the github source fixes it for<br>
>> Mac OS X Mavericks provided the --no-test-load<br>
>> and octave_end tricks are used.<br>
>><br>
>><br>
>> On Tue, Nov 5, 2013 at 9:04 AM, Renaud Gaujoux<br>
>> <<a>renaud@mancala.cbio.uct.ac.za</a>> wrote:<br>
>>><br>
>>> Not sure where the extra '..' would come from.<br>
>>> Are you installing the latest version from github?<br>
>>><br>
>>> devtools::install_github('RcppOctave', 'renozao')<br>
>>><br>
>>><br>
>>><br>
>>> On 2 November 2013 07:00, Dominick Samperi <<a>djsamperi@gmail.com</a>> wrote:<br>
>>>><br>
>>>> It appears that octave_end is not called at all under Mac OS X. But it<br>
>>>> is also not called under Linux! I inserted Rprintf statements to check.<br>
>>>><br>
>>>> Perhaps the explanation is that failing to call octave_end under Linux<br>
>>>> (or Windows?) is non-fatal, but this is fatal under Mac OS X? If this<br>
>>>> is so the Mac OS X behavior is less dangerous...<br>
>>>><br>
>>>> If I do not use --no-test-load, I get the result in RcppOctave.log<br>
>>>> (attached)</div></div></blockquote></div></div></div></div></blockquote></div></div></blockquote>
</div>