[R-SIG-Mac] Testing R 3.4.0 RC r72542

[Simon Urbanek]

> On Apr 19, 2017, at 12:53 PM, Berend Hasselman <bhh at xs4all.nl> wrote:
> 
> Simon,
> 
> 
>> On 19 Apr 2017, at 15:44, Simon Urbanek <simon.urbanek at r-project.org> wrote:
>> 
>>> 
>>> On Apr 19, 2017, at 4:21 AM, Berend Hasselman <bhh at xs4all.nl> 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
>