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 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) 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. Berend
Testing R 3.4.0 RC r72542
9 messages · Simon Urbanek, Berend Hasselman
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: $ 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).
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. Thanks, Simon
Berend
_______________________________________________ R-SIG-Mac mailing list R-SIG-Mac at r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Ok, found the issue with 3. -- it works just fine on Sierra, but there is a bug in El Capitan which fails to accept 127.0.0.1 in the ATS exception list so it's in fact impossible to white-list it. Apple has fixed that bug in Sierra but not in El Capitan, so I have added a work-around by forcing the use of localhost instead. I have also kicked-off another build so the latest RC with the fix (GUI r7337) should be up in another 15 mins at http://R.research.att.com. Thanks, Simon
On Apr 19, 2017, at 9:44 AM, 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: $ 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).
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. Thanks, Simon
Berend
_______________________________________________ R-SIG-Mac mailing list R-SIG-Mac at r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-mac
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.
$ 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?
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. Berend
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
On 19 Apr 2017, at 19:11, Simon Urbanek <simon.urbanek at r-project.org> wrote:
......
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).
Done that. Rcpp.so now links to libc++.1.dylib in the R framework.
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.
I've now done this in my Makevars. And all is well. Thanks for all of your efforts. Berend
On 19 Apr 2017, at 16:24, Simon Urbanek <simon.urbanek at r-project.org> wrote: Ok, found the issue with 3. -- it works just fine on Sierra, but there is a bug in El Capitan which fails to accept 127.0.0.1 in the ATS exception list so it's in fact impossible to white-list it. Apple has fixed that bug in Sierra but not in El Capitan, so I have added a work-around by forcing the use of localhost instead. I have also kicked-off another build so the latest RC with the fix (GUI r7337) should be up in another 15 mins at http://R.research.att.com.
I just downloaded http://r.research.att.com/el-capitan/R-3.4-branch/R-3.4-branch-el-capitan-signed.pkg. When I start up R.app I still get: [R.app GUI 1.70 (7334) x86_64-apple-darwin15.6.0] thanks, Berend
On Apr 19, 2017, at 1:48 PM, Berend Hasselman <bhh at xs4all.nl> wrote:
On 19 Apr 2017, at 16:24, Simon Urbanek <simon.urbanek at r-project.org> wrote: Ok, found the issue with 3. -- it works just fine on Sierra, but there is a bug in El Capitan which fails to accept 127.0.0.1 in the ATS exception list so it's in fact impossible to white-list it. Apple has fixed that bug in Sierra but not in El Capitan, so I have added a work-around by forcing the use of localhost instead. I have also kicked-off another build so the latest RC with the fix (GUI r7337) should be up in another 15 mins at http://R.research.att.com.
I just downloaded http://r.research.att.com/el-capitan/R-3.4-branch/R-3.4-branch-el-capitan-signed.pkg. When I start up R.app I still get: [R.app GUI 1.70 (7334) x86_64-apple-darwin15.6.0]
I'm not sure why the first pass didn't update, but it should be up to date now. Thanks, Simon
Simon,
On 19 Apr 2017, at 21:43, Simon Urbanek <simon.urbanek at r-project.org> wrote:
On Apr 19, 2017, at 1:48 PM, Berend Hasselman <bhh at xs4all.nl> wrote:
On 19 Apr 2017, at 16:24, Simon Urbanek <simon.urbanek at r-project.org> wrote: Ok, found the issue with 3. -- it works just fine on Sierra, but there is a bug in El Capitan which fails to accept 127.0.0.1 in the ATS exception list so it's in fact impossible to white-list it. Apple has fixed that bug in Sierra but not in El Capitan, so I have added a work-around by forcing the use of localhost instead. I have also kicked-off another build so the latest RC with the fix (GUI r7337) should be up in another 15 mins at http://R.research.att.com.
I just downloaded http://r.research.att.com/el-capitan/R-3.4-branch/R-3.4-branch-el-capitan-signed.pkg. When I start up R.app I still get: [R.app GUI 1.70 (7334) x86_64-apple-darwin15.6.0]
I'm not sure why the first pass didn't update, but it should be up to date now.
Thank you. For example ?ls now shows the relevant help page. BTW. I have noticed that several R packages (such as dplyr) using C++ still link to /usr/local/clang4/lib/. But for example caTools and cubature link to the libc++.1.dylib in the R framework. I'll try again tomorrow. Thanks again. Berend
Thanks, Simon