Thanks Simon,

This thread fragment does not explain how the problems were ultimately
resolved. Yes, one aspect of the problem was related to Mavericks ABI
(or tool chain) issues.

But another important factor was due to confusion about how R
cleans up on exit. It turns out that Octave cleanup code was not
being called as expected. See
http://permalink.gmane.org/gmane.comp.lang.r.devel/34833

This was fixed (by Renaud) by adding a call to reg.finalizer().
Obviously this issue is not MacOS-specific.

Dominick


On Wed, Nov 13, 2013 at 9:22 AM, Simon Urbanek
<[email protected]>wrote:

> Dominick,
>
> you may want to follow recent thread on Mavericks here - it discussed the
> ABI incompatibility of gcc and clang as well as the tools options.
>
> Cheers,
> Simon
>
>
> On Oct 30, 2013, at 11:12 PM, Dominick Samperi <[email protected]>
> wrote:
>
> > Hello,
> >
> > The following strange behavior under Mac OS was distilled from
> > attempts to resolve problems with the RcppOctave package, but
> > the problem will be illustrated without use of this package.
> >
> > Basically, when I try to mix use of the Octave library with
> > Rcpp, there is a memory exception when the Mac dlopen() is used to
> > open Rcpp.so (the error occurs in loadLibrary()). To reproduce,
> > simply drop the two attached files (Makevars and strtest.cpp) into
> > Rcpp/src. Then 'R CMD INSTALL Rcpp' will fail with a memory problem,
> > at least sometimesÂ…
> >
> > I say "sometimes" because this problem did not occur before I
> > reinstalled Mac OS X 10.8 (because the update to Mavericks
> > failed). On the other hand, it did occur before the update when I
> > tried to use an older version of Octave (installed by MacPorts).
> > For this test the latest version of Octave (3.6.4) was installed
> > using homebrew.
> >
> > Note that the trivial source file strtest.cpp defines one function
> > that is not actually called! Just instantiating the Octave
> > class string_vector is enough to trigger the problem. If the
> > line using string_vector is commented out there is no problem.
> > It may also not occur if you have older software installed?
> >
> > After the OS reinstall, and after installing the latest version of the
> > command line tools, there is no llvm-gcc-4.2 and llvm-g++-4.2
> > like there was previously?
> >
> > The problem is clearly related to how templates are instantiated
> > (or not instantiated) when using clang++ or g++, possibly a version
> > mismatch, or some Mac OS environmental issue that I have not
> > been able to isolate. Static initialization may also be a factor.
> >
> > The last post in this link seems to address a related issue...
> > https://bugs.launchpad.net/pocl/+bug/1005329
> >
> > This messy problem raises the question: what is in store
> > for R under Mac OS X going forward? Apple is dropping support
> > for gfortran, and even for gcc/g++, so will clang/clang++ be
> > used? What about Fortran? DragonEgg?
> >
> > Thanks,
> > Dominick
> >
> > <Makevars><strtest.cpp>_______________________________________________
> > R-SIG-Mac mailing list
> > [email protected]
> > https://stat.ethz.ch/mailman/listinfo/r-sig-mac
>
>

        [[alternative HTML version deleted]]

_______________________________________________
R-SIG-Mac mailing list
[email protected]
https://stat.ethz.ch/mailman/listinfo/r-sig-mac

Reply via email to