> On Apr 19, 2017, at 12:53 PM, Berend Hasselman <[email protected]> wrote: > > Simon, > > >> On 19 Apr 2017, at 15:44, Simon Urbanek <[email protected]> wrote: >> >>> >>> On Apr 19, 2017, at 4:21 AM, Berend Hasselman <[email protected]> wrote: >>> >>> >>> Most of the problems I mentioned yesterday with R 3.4.0 RC still exist. >>> (see thread >>> https://stat.ethz.ch/pipermail/r-sig-mac/2017-April/012287.html). >>> >>> There is now a libc++ in the R framework: >>> /Library/Frameworks/R.framework/Versions/3.4/Resources/lib/libc++.1.dylib >>> >>> 1. >>> >>> Rcpp was not updated and thus still links to >>> /usr/local/clang4/lib/libc++.1.dylib and not to >>> /Library/Frameworks/R.framework/Versions/3.4/Resources/lib/libc++.1.dylib >>> >> >> It has been updated, but so you're likely using a mirror that has not synced >> yet: >> > > I'm using https://cran.r-project.org in R.app > I'll wait and try later or tomorrow. >
Or use http://r.research.att.com as your CRAN mirror (it is the master for Mac binaries). >> $ otool -L libs/Rcpp.so >> libs/Rcpp.so: >> Rcpp.so (compatibility version 0.0.0, current version 0.0.0) >> /Library/Frameworks/R.framework/Versions/3.4/Resources/lib/libR.dylib >> (compatibility version 3.4.0, current version 3.4.0) >> >> /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation >> (compatibility version 150.0.0, current version 1259.0.0) >> >> /Library/Frameworks/R.framework/Versions/3.4/Resources/lib/libc++.1.dylib >> (compatibility version 1.0.0, current version 1.0.0) >> /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current >> version 1226.10.1) >> >> >> >>> 2. >>> >>> The private package using C++ still links to Apple's libc++.1.dylib and >>> not the one from clang4. >>> Nor to the libc++.1.dylib in the R framework. >>> It is however being built with clang4 using the method suggested by Simon. >>> >>> Output from otool -L ..: >>> >>> regts.so: >>> regts.so (compatibility version 0.0.0, current version 0.0.0) >>> /Library/Frameworks/R.framework/Versions/3.3/Resources/lib/libR.dylib >>> (compatibility version 3.3.0, current version 3.3.3) >>> >>> /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation >>> (compatibility version 150.0.0, current version 1259.0.0) >>> /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version >>> 120.1.0) >>> /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current >>> version 1226.10.1) >>> >> >> Regular look up rules apply, so you probably want to add >> -L/usr/local/clang4/lib to your Makevars when you're setting CC/CXX to >> clang4. Another alternative is to symlink libc++/c++abi from clang into >> /usr/local/lib (then you may as well symlink clang/clang++ to /usr/local/bin >> and don't need any extra flags at all). >> >> > > I've used your suggestion for symlinks. > The .so of the private package mentioned earlier now links correctly to > /usr/local/clang4/lib/libc++.1.dylib > > Would it be possible to have the symlinks done automatically in a package for > installing clang4 with a script to make the symlinks? > The main problem is that it's really a user choice. If you want to make clang4 your system-wide default then you can create the symlinks, but if you want to keep both Apple clang and clang4 in parallel then you would use CC/CXX/LDFLAGS to adjust it instead. I'm not sure what is the best way to handle this - different people may have different preferences. >> >>> 3. >>> >>> The problem with help pages in R.app I mentioned in my second mail still >>> exist. >>> (using [R.app GUI 1.70 (7334) x86_64-apple-darwin15.6.0]). >>> >>> For example after ?ls this message appears. >>> >>> starting httpd help server ... done >>> 2017-04-19 10:14:31.505 R[3447:52508] App Transport Security has blocked a >>> cleartext HTTP (http://) resource load since it is insecure. Temporary >>> exceptions can be configured via your app's Info.plist file. >>> >>> And the window displaying the help is blank. >>> Any request for help using ? of help() shows a blank window. >>> >> >> Are you building R.app yourself or is this from the binary? The CRAN binary >> should have this problem fixed since 2017/03/23 and I'm not seeing it on my >> test Sierra machine. However, I have only committed it into the SVN sources >> today so if you build from source the fix wouldn't show up until today. >> > > R.app is from the binary. From the release candidate .pkg on > r.research.att.com > I don't compile R or R.app in macOS. > I am running macOS El-Capitan 10.11.6. > Thanks, like I said in the follow-up email it turned out to be 10.11 bug (which is why I didn't see it in 10.12) and the current binary should have the fix. Thanks, Simon > Berend > _______________________________________________ R-SIG-Mac mailing list [email protected] https://stat.ethz.ch/mailman/listinfo/r-sig-mac
