Thanks Romain,
I’ll come back to this thread when I found out what the reason of this behavior
in my environment is.
Best
Simon
On 02 Nov 2013, at 10:46, Romain Francois wrote:
> compileAttributes ends up calling a .Call function that lives inside Rcpp.so.
>
> Le 2 nov. 2013 à 10:25, Simon
compileAttributes ends up calling a .Call function that lives inside Rcpp.so.
Le 2 nov. 2013 à 10:25, Simon Zehnder a écrit :
> Thanks Romain,
>
> looks the same here. So the path is the same, but it seems, that the padding
> is different. I would like to understand what happens when I call
Thanks Romain,
looks the same here. So the path is the same, but it seems, that the padding is
different. I would like to understand what happens when I call
compileAttributes. Is there anywhere a linking involved with Rcpp.so or
Rcpp.dylib?
Best
Simon
On 02 Nov 2013, at 09:57, Romain Fra
Le 02/11/2013 09:35, Simon Zehnder a écrit :
First, I didn’t. But for getting some output from the functions in
attributes.cpp I later compiled the Rcpp package from source. When I compile
with the option “-headerpad_max_install_names” the compileAttributes runs
without an error. If I compile
First, I didn’t. But for getting some output from the functions in
attributes.cpp I later compiled the Rcpp package from source. When I compile
with the option “-headerpad_max_install_names” the compileAttributes runs
without an error. If I compile without this flag, I get the pointer error.
Pr
Did you install Rcpp from source? That's what I had to do to solve a
similar problem.
Hadley
On Friday, November 1, 2013, Simon Zehnder 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 :)
>
> Afterwa
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 wrote:
> I assumed incorrectly that getting
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 p
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
reinstalle
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 too
gettext guess is nonsense…
On 01 Nov 2013, at 20:02, Simon Zehnder 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 d
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
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 upd
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
J.J.,
I went now on the cluster Linux Scientific and used there compileAttributes
(also with gcc-4.8.2). There were no problems.
On my Mac I figured out, where exactly in the compileAttributes function in
attributes.cpp the error happens:
On line 2794 with generators.writeBegin()
And further
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
* did not install files from brew *
On 01 Nov 2013, at 17:12, Simon Zehnder 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 wrote:
>
>> If you depend on tools installed using
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 wrote:
> If you depend on tools installed using brew, you might want to try
> removing those that were installed before the Mavericks update,
> using:
Simon,
The other use was also using gcc-4.8.1 so it's got something to do with
that (I don't have a local install of gcc-4.8.1 so can't repo offhand). If
you are running compileAttributes inside RStudio it will run in a separate
process. If not then I don't know of any significant difference betwe
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
On Fri, Nov 1, 2013 at 11:19 AM, Simon Zehnder wrote:
> Point landing J.J.!
>
> I already compi
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
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 Ma
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
23 matches
Mail list logo
