[Rcpp-devel] Attribute does not compile with 'compileAttributes' but with 'sourceCpp'
Dominick Samperi
djsamperi at gmail.com
Fri Nov 1 22:34:48 CET 2013
Correction: my assumption was not completely wrong. RcppOctave works
now with a minor tweak (.Call('octave_end') before terminating R). So
cleaning up the Mac OS X environment did indeed fix this issue.
On Fri, Nov 1, 2013 at 4:24 PM, Dominick Samperi <djsamperi at gmail.com>wrote:
> I assumed incorrectly that getting the pure Octave test working would
> imply that
> RcppOctave will work. I just checked, and I'm seeing the same memory fault
> that you see. As I mentioned in the rcppoctave-users thread even the pure
> Octave
> test will fail (for the same reason) if it is not terminated properly, and
> it appears that
> the way the embedded session is terminated in RcppOctave may not be correct
> in the Mac OS X environment. Further comments on this will move to
> rcppoctave-users
> list...
>
>
> On Fri, Nov 1, 2013 at 3:44 PM, Simon Zehnder <szehnder at uni-bonn.de>wrote:
>
>> Same thing actually on my side: I had a hardware crash lately with 10.8
>> and made fresh install after formatting my harddrive NSA-style :)
>>
>> Afterwards I compiled R 3.0.1 and from macports the gcc48 port as well as
>> gettext. Then, Mavericks came and I updated - nothing worked anymore: I
>> reinstalled gcc48 port and deleted R 3.0.1. Then I installed gcc4.8.2 from
>> http://hpc.sourceforge.net, Xcode Command line tools for Mavericks and
>> XQuartz 4.7.2. I work with environment modules, where I can load a certain
>> compiler with its needed environment variables. With gcc 4.8.2 I installed
>> R-3.0.2 and then the packages. Always have to type “module load
>> compilers/gcc-4.8.2 before starting R, but that doesn’t bother me … I still
>> can use openMP to its great extent :)
>>
>> My problem is linked to the install_name_tool and the way on Mac OS paths
>> are set and replaced in dynamic libraries … this could of course be caused
>> by “older tools” like the llvm-gcc4.2 “laying” around…. though locate does
>> not find them….
>>
>>
>>
>> On 01 Nov 2013, at 20:33, Dominick Samperi <djsamperi at gmail.com> wrote:
>>
>> > My original attempt to update to Mavericks failed (unrelated hardware
>> issue), and this
>> > may have actually worked in my favor. It forced me to install Mac OS X
>> 10.8 from
>> > scratch, a "clean" install, that I later upgraded to Mavericks. If you
>> upgraded from
>> > an existing configuration you may have old tools (like llvm-g++-4.2)
>> laying around
>> > that could cause problems.
>> >
>> >
>> > On Fri, Nov 1, 2013 at 3:02 PM, Simon Zehnder <szehnder at uni-bonn.de>
>> wrote:
>> > I read through all the thread answers and my variables in the Makeconf
>> are the same alsso I installed the Xcode Command Line Tools for Mavericks.
>> Are there any other apps and libs that have been to be updated? (I do not
>> use brew). What remains is the following:
>> >
>> > Compiling Rcpp give the pointer exception (when calling
>> compileAttributes), also encountered in the thread you referred to.
>> >
>> > Compiling Rcpp and adding the flag “-headerpad_max_install_names” lets
>> the compileAttributes function do its work without any exception. My next
>> guess is: possibly the gettext library…
>> >
>> > Best
>> >
>> > Simon
>> >
>> > On 01 Nov 2013, at 19:20, Dominick Samperi <djsamperi at gmail.com> wrote:
>> >
>> > > In your original post you mention the "pointer being freed was not
>> allocated" error message. I have just tracked this down in another context
>> (Octave
>> > > under Mac OS X). In my case the error occurs on the dlopen() call for
>> > > an R package shared library. The fix was to make sure all apps and
>> libs
>> > > are updated after moving to Mavericks. See the thread in
>> rcppoctave-users
>> > > list for a blow-by-blow description.
>> > >
>> > >
>> > > On Fri, Nov 1, 2013 at 1:11 PM, Simon Zehnder <szehnder at uni-bonn.de>
>> wrote:
>> > > You are right, working with apple and C++ is often a mess. Up to now,
>> llvm does not yet support openmp. It is coming but I do not see it fully
>> implemented before next summer. If I want to use openmp I have thus to rely
>> on the gcc which brings a lot of problems with it and from what I read on
>> the R-lists most of the Mac Users suffer. I guess that this time a
>> reinstall of R was unavoidable for most of us. I thought about using the
>> xcrun —find gcc/g++ etc. to get what is needed in a Makevars but this does
>> not give anything so far.
>> > >
>> > >
>> > > On 01 Nov 2013, at 17:50, Dominick Samperi <djsamperi at gmail.com>
>> wrote:
>> > >
>> > > > With Apple moving from gcc/g++ to LLVM/clang++ I guess it makes
>> sense
>> > > > for R/Rcpp to use the LLVM/clang++ tool chain eventuallly, but I
>> don't know
>> > > > if there are plans to do this. Otherwise, the R community would
>> need to
>> > > > support "MACtools" following the model provided by "Rtools" under
>> Windows...
>> > > >
>> > > >
>> > > > On Fri, Nov 1, 2013 at 12:12 PM, Simon Zehnder <
>> szehnder at uni-bonn.de> wrote:
>> > > > Hi Dominick,
>> > > >
>> > > > I did install files from brew but instead used the gcc from
>> http://hpc.sourceforge.net
>> > > >
>> > > >
>> > > > On 01 Nov 2013, at 16:55, Dominick Samperi <djsamperi at gmail.com>
>> wrote:
>> > > >
>> > > > > If you depend on tools installed using brew, you might want to try
>> > > > > removing those that were installed before the Mavericks update,
>> > > > > using:
>> > > > > rm -rf /usr/local/Cellar
>> > > > > brew prune
>> > > > > brew doctor
>> > > > > brew install <what-you-need>
>> > > > >
>> > > > >
>> > > > > On Fri, Nov 1, 2013 at 11:19 AM, Simon Zehnder <
>> szehnder at uni-bonn.de> wrote:
>> > > > > Point landing J.J.!
>> > > > >
>> > > > > I already compiled a new R when Mavericks came out with a newly
>> installed a gcc-4.8.2, that I can load via environment modules. I also
>> installed the Xcode Command Line Tools for Mavericks.
>> > > > >
>> > > > > I now reinstalled Rcpp with the gcc-4.8.2 and threw away all
>> object and shared-object files in my /src/ folder of my package. The
>> problem remains. Is there something special I can look for in my Makeconf
>> file? What is so different about ‘compileAttributes’ in contrast to
>> ‘sourceCpp’ or a usual package compilation via R CMD INSTALL? Does
>> compileAttributes uses some additional flags and/or libraries?
>> > > > >
>> > > > > Best
>> > > > > Simon
>> > > > >
>> > > > >
>> > > > >
>> > > > > On 01 Nov 2013, at 15:56, JJ Allaire <jj.allaire at gmail.com>
>> wrote:
>> > > > >
>> > > > > > Are you by any chance on OS X Mavericks? I had one other user
>> report this specific error on Mavericks and it seemed to be related to the
>> use of different compilers (and thus different heaps) within the same
>> compilation (there is exposure to this with the changes made by Apple to
>> the toolchain in Mavericks).
>> > > > > >
>> > > > > > J.J.
>> > > > > >
>> > > > > >
>> > > > > > On Fri, Nov 1, 2013 at 10:01 AM, Simon Zehnder <
>> szehnder at uni-bonn.de> wrote:
>> > > > > > Dear Rcpp::Users and Rcpp::Devels,
>> > > > > >
>> > > > > > I get a weird exception when I try to compile an attribute in
>> one of my packages:
>> > > > > >
>> > > > > > compileAttributes("/Users/simonzehnder/git/mmstruct/mmstruct/")
>> > > > > > R(6256,0x7fff79ad9310) malloc: *** error for object
>> 0x7fff7ac48330: pointer being freed was not allocated
>> > > > > > *** set a breakpoint in malloc_error_break to debug
>> > > > > > Abort trap: 6
>> > > > > >
>> > > > > > If I instead use the sourceCpp function all works fine:
>> > > > > >
>> > > > > >
>> sourceCpp("/Users/simonzehnder/git/mmstruct/mmstruct/src/testing.cpp”)
>> > > > > > testfunction_cc(c(0,0,0), list(trades = rnorm(10), T = 360))
>> > > > > > [1] 0.000000e+00 3.509927e-05 1.169976e-05
>> > > > > >
>> > > > > > The function in my file is actually pretty simple (and its the
>> only one):
>> > > > > >
>> > > > > > #include<Rcpp.h>
>> > > > > >
>> > > > > > // [[Rcpp::export]]
>> > > > > >
>> > > > > > Rcpp::NumericVector testfunction_cc(Rcpp::NumericVector par,
>> > > > > > Rcpp::List list)
>> > > > > > {
>> > > > > > const unsigned int K = par.size();
>> > > > > > Rcpp::NumericVector trades = list["trades"];
>> > > > > > const unsigned int T = list["T"];
>> > > > > > double tmp = mean(trades)/T;
>> > > > > > std::vector<double> startp(K);
>> > > > > > startp[0] = 0.0;
>> > > > > > startp[1] = tmp * 0.75/2;
>> > > > > > startp[2] = tmp * 0.25/2;
>> > > > > >
>> > > > > > return Rcpp::wrap(startp);
>> > > > > > }
>> > > > > >
>> > > > > > At this moment I am a little perplexed. Where should I search
>> for a possible error? What are things to try out?
>> > > > > >
>> > > > > > Best
>> > > > > >
>> > > > > > Simon
>> > > > > >
>> > > > > > _______________________________________________
>> > > > > > Rcpp-devel mailing list
>> > > > > > Rcpp-devel at lists.r-forge.r-project.org
>> > > > > >
>> https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
>> > > > > >
>> > > > >
>> > > > > _______________________________________________
>> > > > > Rcpp-devel mailing list
>> > > > > Rcpp-devel at lists.r-forge.r-project.org
>> > > > >
>> https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
>> > > > >
>> > > >
>> > > >
>> > >
>> > >
>> >
>> >
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.r-forge.r-project.org/pipermail/rcpp-devel/attachments/20131101/8a540dab/attachment-0001.html>
More information about the Rcpp-devel
mailing list