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
