[Rcppoctave-user] Apple Blues
Dominick Samperi
djsamperi at gmail.com
Wed Nov 6 16:25:40 CET 2013
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).
> >>>>
> >>>> Also, I'm attaching RcppOctave/src/modules/Makefile.in
> >>>> with a small edit (the sed script generates a path with an extra
> '..').
> >>>>
> >>>>
> >>>>
> >>>> On Sat, Nov 2, 2013 at 12:19 AM, Renaud Gaujoux
> >>>> <renaud at mancala.cbio.uct.ac.za> wrote:
> >>>>>
> >>>>>
> >>>>>> The --no-test-load option is used because the embedded Octave
> session
> >>>>>> is not terminated properly at test time (during installation), and
> the
> >>>>>> embedded Octave session needs to be explicitly terminated before
> >>>>>> leaving the R session using the 'octave_end' entry point.
> >>>>>
> >>>>>
> >>>>> octave_end is normally called when the package is unloaded in
> .onUnload
> >>>>> as well as when the library is unloaded by in R_init_unload (or
> something
> >>>>> like that).
> >>>>> There is no errors on Linux at load test.
> >>>>> Can you please post the install logs showing the error?
> >>>>>
> >>>>> Thanks
> >>>>
> >>>>
> >>>
> >>
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.r-forge.r-project.org/pipermail/rcppoctave-user/attachments/20131106/0f0f9d1e/attachment.html>
More information about the Rcppoctave-user
mailing list