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 without this flag, I get the pointer error.
Problems with header padding is a well-known issue on the Mac
(https://svn.boost.org/trac/boost/ticket/1927), usually in frameworks. It is
used a relative path in the sections of shared objects (sometimes also in
dynamic libs). When the library/shared object has to be included in other
libraries, the relative path has to be changed to an absolute path. If then
there is not enough space in the header of the Mach-O file, it gives you an
exception.
But my guess is for the compileAttributes function, that no library binding is
done, though it takes library paths as arguments when calling ‘.Call’. My
perception has been so far, that this function solely creates the
RcppExports.cpp and *.R files without any compilation or linking (this is done
later, when we compile the package with the attributes). The depends/linkingto
names from the DESCRIPTION file are used for headers in the RcppExports.cpp
file I have guessed. The point, that I am seemingly the only one, that
encounters this error, points me to my compiler (gcc4.8.2). Could be, that
under the hood clang uses already a larger header padding.
Btw: When you are on Mac, could you check what “otool -L Rcpp.so” give you? Is
the path relative (Rcpp.so) or absolute (has it something like @exectuable_path
in front)?
$ otool -L Rcpp.so
Rcpp.so:
Rcpp.so (compatibility version 0.0.0, current version 0.0.0)
/Library/Frameworks/R.framework/Versions/3.0/Resources/lib/libR.dylib
(compatibility version 3.0.0, current version 3.0.2)
/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation
(compatibility version 150.0.0, current version 855.11.0)
/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version
120.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
version 1197.1.1)
Best
Simon
On 02 Nov 2013, at 01:02, Hadley Wickham <[email protected]> wrote:
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 :)
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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 th
--
Chief Scientist, RStudio
http://had.co.nz/
_______________________________________________
Rcpp-devel mailing list
[email protected]
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
--
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30
_______________________________________________
Rcpp-devel mailing list
[email protected]
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
