> On Apr 19, 2017, at 4:21 AM, Berend Hasselman <b...@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@r-project.org
> https://stat.ethz.ch/mailman/listinfo/r-sig-mac
>
_______________________________________________
R-SIG-Mac mailing list
R-SIG-Mac@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-mac
