Simon,
The link I provided to the httpuv issue has detailed information about
the error:
https://github.com/rstudio/httpuv/issues/260
The error occurs when I run the following (although note, depending on
which mirror you use, the recent CRAN server issues may result in
problems downloading the packages):
install.packages("Rcpp")
install.packages("httpuv", type = "source")
Here's the full output:
https://gist.github.com/wch/c70b438381c9d2a8b1f917b054e0ba7e
Here's an example of the errors:
In file included from staticpath.cpp:1:
In file included from ./staticpath.h:7:
In file included from /Users/winston/R/3.6/BH/include/boost/optional.hpp:15:
In file included from
/Users/winston/R/3.6/BH/include/boost/optional/optional.hpp:28:
In file included from
/Users/winston/R/3.6/BH/include/boost/core/addressof.hpp:17:
In file included from /Users/winston/R/3.6/BH/include/boost/config.hpp:57:
In file included from
/Users/winston/R/3.6/BH/include/boost/config/platform/macos.hpp:28:
In file included from
/Users/winston/R/3.6/BH/include/boost/config/detail/posix_features.hpp:18:
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/unistd.h:664:27:
error: unknown type name 'uuid_t'; did you mean 'uid_t'?
int getwgroups_np(int *, uuid_t);
^
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/sys/_types/_uid_t.h:31:31:
note: 'uid_t' declared here
typedef __darwin_uid_t uid_t;
^
This issue describes the same problem:
https://github.com/RcppCore/Rcpp/issues/1046
And it has been fixed in the development version of Rcpp by:
https://github.com/RcppCore/Rcpp/pull/1047
I know that Kevin Ushey has tried building with the CRAN-recommended
clang 7 toolchain and encountered the same errors. I haven't done that
yet myself, though.
-Winston
On Thu, Mar 26, 2020 at 4:00 PM Simon Urbanek
<simon.urba...@r-project.org> wrote:
>
> Winston,
>
> the Mac CRAN build builds a package only if either is true:
> 1) the package has not passed checks
> 2) there is a new version of the package since last successful build+check
>
> The old build machine doesn't have the capacity to do full re-builds (it
> would take over 24h - currently the nightly build of packages takes 16-22
> hours), but we're currently building a new setup for R 4.0.0 on new hardware
> and as a part of it we are planning to setup a "mac-builder" similar to what
> is currently available for Windows.
>
> That said, I have run httpuv by hand on the CRAN build machine (against Rcpp
> 1.0.4) and I saw no issues. I have seen the discussion on Rcpp, but so far no
> one actually posted details of what is breaking (nor do your links include
> any actual details on this). I'd love to help, but the lack fo a useful
> report makes this impossible. If you have any actual leads, please post them.
> The CRAN machine uses the tools that are available on CRAN:
> https://cran.r-project.org/bin/macosx/tools/ (clang-7 and gfortran-6.1 for
> 3.6.x)
>
> Cheers,
> Simon
>
>
> > On 27/03/2020, at 7:38 AM, Winston Chang <winstoncha...@gmail.com> wrote:
> >
> > I have two questions about the CRAN machines that build binary
> > packages for Mac. When a new version of a package is released,
> > (A) Do the downstream dependencies get re-checked?
> > (B) Do the downstream dependencies get re-built?
> >
> > I have heard (but do not know for sure) that the answer to (A) is no,
> > the downstream dependencies do not get rechecked.
> >
> > From publicly available information on the CRAN web server, it looks
> > like the answer to (B) is also no, the downstream dependencies do not
> > get rebuilt. Looking at
> > https://www.r-project.org/nosvn/R.check/r-release-osx-x86_64/, I see
> > the following dates for these binary packages:
> >
> > - Rcpp_1.0.4.tgz: 2020-03-18
> > - httpuv_1.5.2.tgz: 2019-09-12
> > - dplyr_0.8.5.tgz: 2020-03-08
> >
> > Rcpp was released recently, and httpuv and dplyr (which are downstream
> > dependencies of Rcpp) have older dates, which indicates that these
> > binary packages were not rebuilt when Rcpp was released.
> >
> > In my particular case, I'm interested in the httpuv package (which I
> > maintain). I and several others have not been able to get the CRAN
> > version of httpuv to compile using the CRAN version of Rcpp on Mac.
> > (It seems to compile fine on other platforms.) I have heard from
> > maintainers of other Rcpp-dependent packages that they also can't get
> > their packages to compile on Mac, using both the default Mac compiler
> > toolchain and the CRAN-recommended toolchain, which uses clang 7.
> >
> > For more technical details about the cause of breakage, see:
> > https://github.com/RcppCore/Rcpp/issues/1060
> > https://github.com/rstudio/httpuv/issues/260
> >
> > If the CRAN Mac build machine is indeed able to build httpuv against
> > the current version of Rcpp, it would be really helpful to have more
> > information about the system configuration. If it is not able to
> > rebuild httpuv and other packages against Rcpp, then this is a
> > problem. Among other things, it prevents people from building their
> > packages from source using CRAN versions of packages, and it also
> > means that none of these packages can release a new version, because
> > the binaries can't be built on Mac.
> >
> > -Winston
> >
> > ______________________________________________
> > R-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
> >
>
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
