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
