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 <[email protected]> wrote: > compileAttributes ends up calling a .Call function that lives inside Rcpp.so. > > Le 2 nov. 2013 à 10:25, Simon Zehnder <[email protected]> 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 >> compileAttributes. Is there anywhere a linking involved with Rcpp.so or >> Rcpp.dylib? >> >> >> Best >> >> Simon >> >> >> On 02 Nov 2013, at 09:57, Romain Francois <[email protected]> wrote: >> >>> 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 >> _______________________________________________ Rcpp-devel mailing list [email protected] https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
