[Rcppoctave-user] Apple Blues

[Renaud Gaujoux]

I changed configure.ac into:
R_LDFLAGS=`echo "-Wl,$R_LDFLAGS" | sed 's/ /,/'`

as I read/saw that multiple options must be comma separated.
This will break if the path to the R framework contains spaces though.
Can you please try again:

install_github('RcppOctave', 'renozao', ref = 'develop')

Thanks.

Bests,
Renaud

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