From 536345725a6f2378fe874254159045cb56426cea Mon Sep 17 00:00:00 2001 From: Kevin Ushey Date: Wed, 29 Jul 2026 10:32:08 -0700 Subject: [PATCH 1/4] prepare for the 6.2.0 release Consolidate the NEWS entries for this cycle: three of them described intermediate states that later commits superseded, and contradicted the entries above them -- configure no longer probes for an Rtools TBB, and the tbb.dll stub is gone. Also correct the flags documentation, which claimed LdFlags() emits nothing on macOS; that stopped being true in 5.1.8, and this release adds an -rpath there. Drop patches/windows_arm64.diff, which patches files removed with the make-based TBB in 6.0.0 and whose one remaining hunk is now upstream. Exclude .worktrees from the build: R CMD build was sweeping local worktrees into the tarball, 1741 of its 2193 files. --- .Rbuildignore | 1 + .github/workflows/R-CMD-check.yaml | 7 ++-- DESCRIPTION | 2 +- NEWS.md | 57 +++++++++++------------------- R/flags.R | 10 ++++-- R/tbb.R | 8 +++-- cran-comments.md | 37 +++++++++++++++++++ man/flags.Rd | 10 ++++-- patches/windows_arm64.diff | 47 ------------------------ 9 files changed, 83 insertions(+), 96 deletions(-) create mode 100644 cran-comments.md delete mode 100644 patches/windows_arm64.diff diff --git a/.Rbuildignore b/.Rbuildignore index 96d2c4ce..49447ba4 100644 --- a/.Rbuildignore +++ b/.Rbuildignore @@ -19,6 +19,7 @@ ^tools/tbb$ ^\.github$ ^\.claude$ +^\.worktrees$ ^cran-comments\.md$ ^patches ^CRAN-SUBMISSION$ diff --git a/.github/workflows/R-CMD-check.yaml b/.github/workflows/R-CMD-check.yaml index 06216894..4f90524d 100644 --- a/.github/workflows/R-CMD-check.yaml +++ b/.github/workflows/R-CMD-check.yaml @@ -23,8 +23,8 @@ jobs: - {os: ubuntu-24.04-arm, r: 'release'} - {os: windows-latest, r: 'release'} - {os: windows-11-arm, r: 'release'} - # Rtools42 provides only a pre-oneTBB copy of TBB, so this is the - # one configuration that builds the bundled oneTBB on Windows + # the oldest Rtools we build the bundled oneTBB with (gcc 10, and + # the cmake shipped in Rtools42); the newest is covered above - {os: windows-latest, r: '4.2'} env: @@ -58,7 +58,8 @@ jobs: fail-fast: false matrix: config: - # Rtools42 has no oneTBB, so this one builds the bundled copy + # the oldest supported Rtools, and the one rstan could not build + # against while RcppParallel used the TBB it provides - {os: windows-latest, r: '4.2'} - {os: windows-latest, r: 'release'} # RcppParallelLibs() changed for every Windows platform, and arm64 diff --git a/DESCRIPTION b/DESCRIPTION index 472d08ed..0f83903f 100644 --- a/DESCRIPTION +++ b/DESCRIPTION @@ -1,7 +1,7 @@ Package: RcppParallel Type: Package Title: Parallel Programming Tools for 'Rcpp' -Version: 6.1.1.9000 +Version: 6.2.0 Authors@R: c( person("Kevin", "Ushey", role = c("aut", "cre"), email = "kevin@rstudio.com", comment = c(ORCID = "0000-0003-2880-7407")), diff --git a/NEWS.md b/NEWS.md index 58d86609..65509211 100644 --- a/NEWS.md +++ b/NEWS.md @@ -1,12 +1,4 @@ -# RcppParallel (development version) - -* On macOS, `RcppParallel::LdFlags()` now also emits an `-rpath` entry for the - directory containing the TBB libraries. The libraries record an - `@rpath`-relative install name, so packages linking against them previously - produced binaries with no runtime search path for TBB; those binaries could - only be loaded when RcppParallel (and hence TBB) already happened to be - loaded into the process, and failed with "Library not loaded: - @rpath/libtbb.dylib" otherwise. (#209) +# RcppParallel 6.2.0 * On Windows, RcppParallel now builds the bundled oneTBB as a shared library and links against it, shipping `tbb.dll` and `tbbmalloc.dll` alongside the @@ -14,9 +6,14 @@ Previously it linked the static TBB provided by Rtools directly into `RcppParallel.dll`, which meant the TBB version (and ABI) depended on the user's toolchain, and left downstream packages with no TBB library to link - against. Building it ourselves gives every platform the same oneTBB and makes - the ABI a property of RcppParallel. `TBB_LIB` / `TBB_INC` are still honoured - for anyone supplying their own build. + against. Rtools42 in particular provides Intel TBB 2017, whose headers + downstream packages cannot build against: StanHeaders uses + `tbb::this_task_arena::isolate`, which that release still gates behind + `TBB_PREVIEW_TASK_ISOLATION` and does not export from its library, so rstan + could no longer be built on R 4.2 for Windows. Building TBB ourselves gives + every platform the same oneTBB and makes the ABI a property of RcppParallel + rather than of the toolchain. `TBB_LIB` / `TBB_INC` are still honoured for + anyone supplying their own build. (#269, #274) * Building RcppParallel now requires cmake (>= 3.5) on all platforms, as `SystemRequirements` has always declared. Previously a missing or unusable @@ -26,6 +23,7 @@ shipped cmake since Rtools42, so this should not affect Windows users in practice. Note that the tinythread backend remains selectable at runtime via `RCPP_PARALLEL_BACKEND=tinythread`; it is only no longer a build outcome. + (#275) * As a consequence, `RcppParallel::RcppParallelLibs()` now emits `-ltbb` and `-ltbbmalloc` on Windows, in addition to `-lRcppParallel` (which remains @@ -42,43 +40,30 @@ already was by the shared libraries on other platforms, so binaries built against RcppParallel 5.1.11 and earlier continue to resolve it. +* On macOS, `RcppParallel::LdFlags()` now also emits an `-rpath` entry for the + directory containing the TBB libraries. The libraries record an + `@rpath`-relative install name, so packages linking against them previously + produced binaries with no runtime search path for TBB; those binaries could + only be loaded when RcppParallel (and hence TBB) already happened to be + loaded into the process, and failed with "Library not loaded: + @rpath/libtbb.dylib" otherwise. (#209, #271) + * Fixed `RcppParallel::tbbLibraryPath()` returning `NULL` on Windows, and `tbbRoot()` reporting a directory that need not exist on the machine running the package -- for a pre-built binary, the Rtools tree of the machine that - built it. Both now describe the installation actually in use. (#270) + built it. Both now describe the installation actually in use. (#270, #273) * Fixed an issue where compiling code including `tbb/parallel_for_each.h` could fail with toolchains that accept `-std=c++20` but provide a pre-C++20 standard library, with errors of the form "no member named 'random_access_iterator' in namespace 'std'". This affected CRAN's macOS - x86_64 machines, which pair Apple clang 14 with the macOS 11.3 SDK. - -* On Windows, RcppParallel now only uses the copy of TBB provided by Rtools - when that copy is oneTBB; otherwise, the bundled oneTBB is built from - sources, as it already is on other platforms. Rtools42 provides Intel TBB - 2017, whose headers downstream packages cannot build against: StanHeaders - uses `tbb::this_task_arena::isolate`, which that release still gates behind - `TBB_PREVIEW_TASK_ISOLATION` and does not export from its library. As a - result, rstan could no longer be built on R 4.2 for Windows. A TBB - configured explicitly via `TBB_LIB` is still used as-is, whatever its - vintage. - -* On Windows, `RcppParallel::RcppParallelLibs()` once again offers the TBB - stub library, so that packages taking all of their linker flags from it - (e.g. rstan) can resolve TBB symbols which `RcppParallel.dll` does not - itself re-export. - -* Fixed an issue on Windows where a failure to build the TBB stub library - could go unreported, since `R CMD SHLIB` has been seen to exit successfully - even when the link failed. Installation completed, but shipped a package - with no `tbb.dll` -- which packages linking `-ltbb` then discovered only - when they failed to load. Installation now fails instead. + x86_64 machines, which pair Apple clang 14 with the macOS 11.3 SDK. (#268) * Fixed an issue where building the bundled oneTBB could fail when `CXX` (or `CC`) was configured with a leading compiler launcher such as `ccache` (e.g. `CXX = "ccache g++"`). The launcher is now forwarded to cmake via `CMAKE__COMPILER_LAUNCHER` instead of being mistaken for the compiler - itself. + itself. (#267) # RcppParallel 6.1.1 diff --git a/R/flags.R b/R/flags.R index 6ae1f828..40c5dfd0 100644 --- a/R/flags.R +++ b/R/flags.R @@ -9,9 +9,13 @@ #' PKG_LIBS += $(shell "${R_HOME}/bin/Rscript" -e "RcppParallel::LdFlags()") #' ``` #' -#' On Windows, the flags ensure that the package links with the built-in TBB -#' library. On Linux and macOS, the output is empty, because TBB is loaded -#' dynamically on load by `RcppParallel`. +#' What is emitted depends on how TBB is resolved at runtime on each platform. +#' On Windows, every symbol has to be resolved at link time, so the flags name +#' both the TBB libraries RcppParallel ships and RcppParallel itself. On macOS, +#' they name the TBB libraries along with an `-rpath` entry, so that the +#' resulting binary can find them without relying on `RcppParallel` having been +#' loaded first. On Linux, the output is empty: TBB symbols are left undefined +#' at link time and resolved from the libraries `RcppParallel` loads. #' #' \R packages using RcppParallel should also add the following to their #' `NAMESPACE` file: diff --git a/R/tbb.R b/R/tbb.R index 7a773684..6f6a745c 100644 --- a/R/tbb.R +++ b/R/tbb.R @@ -96,9 +96,11 @@ tbbLdFlags <- function() { libsPath <- archSystemFile("libs") ldFlags <- sprintf("-L%s -lRcppParallel", asBuildPath(libsPath)) - # only name the TBB libraries when there are TBB libraries to name: a - # build that fell back to tinythread ships none, and asking the linker - # for them would fail the downstream build outright + # only name the TBB libraries when there are TBB libraries to name; + # asking the linker for one that isn't there would fail the downstream + # build outright. configure always enables TBB, so this should not + # happen -- but a wrong answer here is only discovered by whoever is + # compiling against us, so check rather than assume if (TBB_ENABLED && !is.null(tbbLibraryPath("tbb"))) { fmt <- "%s -L%s -l%s -l%s" ldFlags <- sprintf( diff --git a/cran-comments.md b/cran-comments.md new file mode 100644 index 00000000..aeaff9b9 --- /dev/null +++ b/cran-comments.md @@ -0,0 +1,37 @@ +## RcppParallel 6.2.0 + +This release follows closely on 6.1.1. We apologize for the quick turnaround; +it repairs a regression that leaves Windows users of RcppParallel unable to +build some downstream packages. + +Since 6.0.0, RcppParallel has linked the static TBB provided by Rtools on +Windows. That makes the TBB version, and its ABI, a property of the user's +toolchain rather than of RcppParallel: Rtools42 ships Intel TBB 2017, whose +headers downstream packages cannot build against (StanHeaders requires +`tbb::this_task_arena::isolate`, which that release gates behind a preview +macro and does not export), so rstan can no longer be built from source on +R 4.2 for Windows. It also left downstream packages with no TBB library to +link against. + +RcppParallel now builds the bundled oneTBB as a shared library on Windows and +ships it with the package, as it already does on every other platform. As a +consequence, `RcppParallel::RcppParallelLibs()` now emits `-ltbb` and +`-ltbbmalloc` there in addition to `-lRcppParallel`. Packages that take their +linker flags from that function require no source changes; packages that +hard-coded `-lRcppParallel` to pick up TBB symbols will need to use it. + +Building the bundled oneTBB requires cmake, which is now required on Windows +as well. This matches the `SystemRequirements: CMake (>= 3.5)` that DESCRIPTION +has always declared, and Rtools has shipped cmake since Rtools42, so it should +not affect Windows users in practice. + +## R CMD check results + +0 errors | 0 warnings | 1 note + +The note is the incoming-feasibility check reporting the number of days since +the last update, for the reason described above. + +## revdepcheck results + + diff --git a/man/flags.Rd b/man/flags.Rd index 6401d426..16caa2d0 100644 --- a/man/flags.Rd +++ b/man/flags.Rd @@ -24,9 +24,13 @@ Output the compiler or linker flags required to build against RcppParallel. These functions are typically called from \code{Makevars} as follows:\preformatted{PKG_LIBS += $(shell "$\{R_HOME\}/bin/Rscript" -e "RcppParallel::LdFlags()") } -On Windows, the flags ensure that the package links with the built-in TBB -library. On Linux and macOS, the output is empty, because TBB is loaded -dynamically on load by \code{RcppParallel}. +What is emitted depends on how TBB is resolved at runtime on each platform. +On Windows, every symbol has to be resolved at link time, so the flags name +both the TBB libraries RcppParallel ships and RcppParallel itself. On macOS, +they name the TBB libraries along with an \code{-rpath} entry, so that the +resulting binary can find them without relying on \code{RcppParallel} having been +loaded first. On Linux, the output is empty: TBB symbols are left undefined +at link time and resolved from the libraries \code{RcppParallel} loads. \R packages using RcppParallel should also add the following to their \code{NAMESPACE} file:\preformatted{importFrom(RcppParallel, RcppParallelLibs) diff --git a/patches/windows_arm64.diff b/patches/windows_arm64.diff deleted file mode 100644 index 514f6275..00000000 --- a/patches/windows_arm64.diff +++ /dev/null @@ -1,47 +0,0 @@ -diff --git a/src/tbb/build/Makefile.tbb b/src/tbb/build/Makefile.tbb -index 8d155f80..c58f4fb1 100644 ---- a/src/tbb/build/Makefile.tbb -+++ b/src/tbb/build/Makefile.tbb -@@ -91,7 +91,11 @@ ifneq (,$(TBB.DEF)) - tbb.def: $(TBB.DEF) $(TBB.LST) - $(CPLUS) $(PREPROC_ONLY) $< $(CPLUS_FLAGS) $(INCLUDES) > $@ - --LIB_LINK_FLAGS += $(EXPORT_KEY)tbb.def -+# LLVM on Windows doesn't need --version-script export -+# https://reviews.llvm.org/D63743 -+ifeq (, $(WINARM64_CLANG)) -+ LIB_LINK_FLAGS += $(EXPORT_KEY)tbb.def -+endif - $(TBB.DLL): tbb.def - endif - -diff --git a/src/tbb/build/Makefile.tbbmalloc b/src/tbb/build/Makefile.tbbmalloc -index 421e95c5..e7c38fa4 100644 ---- a/src/tbb/build/Makefile.tbbmalloc -+++ b/src/tbb/build/Makefile.tbbmalloc -@@ -74,7 +74,11 @@ ifneq (,$(MALLOC.DEF)) - tbbmalloc.def: $(MALLOC.DEF) - $(CPLUS) $(PREPROC_ONLY) $< $(M_CPLUS_FLAGS) $(WARNING_SUPPRESS) $(INCLUDES) > $@ - --MALLOC_LINK_FLAGS += $(EXPORT_KEY)tbbmalloc.def -+# LLVM on Windows doesn't need --version-script export -+# https://reviews.llvm.org/D63743 -+ifeq (, $(WINARM64_CLANG)) -+ MALLOC_LINK_FLAGS += $(EXPORT_KEY)tbbmalloc.def -+endif - $(MALLOC.DLL): tbbmalloc.def - endif - -diff --git a/src/tbb/src/tbbmalloc/TypeDefinitions.h b/src/tbb/src/tbbmalloc/TypeDefinitions.h -index 3178442e..fd4b7956 100644 ---- a/src/tbb/src/tbbmalloc/TypeDefinitions.h -+++ b/src/tbb/src/tbbmalloc/TypeDefinitions.h -@@ -25,7 +25,7 @@ - # define __ARCH_ipf 1 - # elif defined(_M_IX86)||defined(__i386__) // the latter for MinGW support - # define __ARCH_x86_32 1 --# elif defined(_M_ARM) -+# elif defined(_M_ARM) || defined(__aarch64__) - # define __ARCH_other 1 - # else - # error Unknown processor architecture for Windows From 3120c9c71d6f37aa368322600d64374b9a075004 Mon Sep 17 00:00:00 2001 From: Kevin Ushey Date: Wed, 29 Jul 2026 10:51:06 -0700 Subject: [PATCH 2/4] lead the release notes with the macos install failure RcppParallel 6.1.1 currently fails to install on r-release-macos-x86_64, which is the most consequential thing 6.2.0 fixes. The NEWS entry framed it as affecting code that includes the header; src/tbb.cpp includes it via RcppParallel/TBB.h, so it broke our own compilation too. --- NEWS.md | 16 ++++++++++------ cran-comments.md | 24 +++++++++++++++++++++--- 2 files changed, 31 insertions(+), 9 deletions(-) diff --git a/NEWS.md b/NEWS.md index 65509211..bc7959b4 100644 --- a/NEWS.md +++ b/NEWS.md @@ -1,5 +1,15 @@ # RcppParallel 6.2.0 +* Fixed a failure to install with toolchains that accept `-std=c++20` but + provide a pre-C++20 standard library, with errors of the form "no member + named 'random_access_iterator' in namespace 'std'" from + `tbb/parallel_for_each.h`. The bundled oneTBB selected its concepts-based + iterator dispatch on a macro testing only the language standard, rather than + the `__TBB_CPP20_CONCEPTS_PRESENT` used elsewhere in that same header. This + affected RcppParallel's own compilation, as well as any package including + the header; CRAN's macOS x86_64 machines, which pair Apple clang 14 with the + macOS 11.3 SDK, are one such toolchain. (#268) + * On Windows, RcppParallel now builds the bundled oneTBB as a shared library and links against it, shipping `tbb.dll` and `tbbmalloc.dll` alongside the package -- the same arrangement already used on every other platform. @@ -53,12 +63,6 @@ the package -- for a pre-built binary, the Rtools tree of the machine that built it. Both now describe the installation actually in use. (#270, #273) -* Fixed an issue where compiling code including `tbb/parallel_for_each.h` - could fail with toolchains that accept `-std=c++20` but provide a - pre-C++20 standard library, with errors of the form "no member named - 'random_access_iterator' in namespace 'std'". This affected CRAN's macOS - x86_64 machines, which pair Apple clang 14 with the macOS 11.3 SDK. (#268) - * Fixed an issue where building the bundled oneTBB could fail when `CXX` (or `CC`) was configured with a leading compiler launcher such as `ccache` (e.g. `CXX = "ccache g++"`). The launcher is now forwarded to cmake via diff --git a/cran-comments.md b/cran-comments.md index aeaff9b9..fd97cc0d 100644 --- a/cran-comments.md +++ b/cran-comments.md @@ -1,8 +1,26 @@ ## RcppParallel 6.2.0 -This release follows closely on 6.1.1. We apologize for the quick turnaround; -it repairs a regression that leaves Windows users of RcppParallel unable to -build some downstream packages. +This release follows closely on 6.1.1, and we apologize for the quick +turnaround. It fixes the installation failure currently reported for 6.1.1 on +r-release-macos-x86_64, along with a regression that leaves Windows users +unable to build some downstream packages from source. + +### Installation failure on r-release-macos-x86_64 + +RcppParallel 6.1.1 fails to install on that machine, with: + + no member named 'random_access_iterator' in namespace 'std' + +The bundled oneTBB guarded a concepts-based iterator dispatch in +`parallel_for_each.h` on a macro that only tests the language standard. With a +toolchain that accepts `-std=c++20` but provides a pre-C++20 standard library +-- Apple clang 14 with the macOS 11.3 SDK, as on that check machine -- it +therefore reached for `std::random_access_iterator`, which is not available. +oneTBB already defines `__TBB_CPP20_CONCEPTS_PRESENT` as 0 for clang, and +guards the rest of that header on it; this release uses it for the dispatch +block as well, so the pre-C++20 fallback is selected as intended. + +### Downstream builds on Windows Since 6.0.0, RcppParallel has linked the static TBB provided by Rtools on Windows. That makes the TBB version, and its ABI, a property of the user's From 51a63a9ad17755d02a549bf2fc095150dff172ef Mon Sep 17 00:00:00 2001 From: Kevin Ushey Date: Wed, 29 Jul 2026 11:41:40 -0700 Subject: [PATCH 3/4] record revdepcheck results for 6.2.0 --- cran-comments.md | 31 ++++++++++++++++++++++++++++++- 1 file changed, 30 insertions(+), 1 deletion(-) diff --git a/cran-comments.md b/cran-comments.md index fd97cc0d..fd3c7689 100644 --- a/cran-comments.md +++ b/cran-comments.md @@ -52,4 +52,33 @@ the last update, for the reason described above. ## revdepcheck results - +We checked 307 reverse dependencies (276 from CRAN + 31 from Bioconductor), +comparing R CMD check results across CRAN and dev versions of this package. + + * We saw 0 new problems + * We failed to check 9 packages + +### Failed to check + +* bayesdfa (NA) +* BayesPET (NA) +* blavaan (NA) +* bmgarch (NA) +* ctsem (NA) +* GeneralizedUmatrixGPU (NA) +* multinma (NA) +* rmsb (NA) +* TriDimRegression (NA) + +None of these are attributable to this release. Each failed identically +against the released version in the same run -- they could not be installed +in the check environment -- and all nine were already failing in our previous +revdepcheck. + +That previous run had sixteen such failures; the six that no longer fail +(CompositionalRF, DER, kernreg, qs2, Rfast2, rxode2) are the ones we reported +with 6.0.0 as needing a rebuild against the new oneTBB ABI, which has since +happened. + +One further reverse dependency, 'rmdcev', had not finished checking when this +was written. It also failed to check in our previous run. From dbebac9b6e2a1fd130becebefcc4e25cbe6c6d87 Mon Sep 17 00:00:00 2001 From: Kevin Ushey Date: Wed, 29 Jul 2026 12:00:43 -0700 Subject: [PATCH 4/4] record cran submission for 6.2.0 --- CRAN-SUBMISSION | 3 +++ 1 file changed, 3 insertions(+) create mode 100644 CRAN-SUBMISSION diff --git a/CRAN-SUBMISSION b/CRAN-SUBMISSION new file mode 100644 index 00000000..2308fa92 --- /dev/null +++ b/CRAN-SUBMISSION @@ -0,0 +1,3 @@ +Version: 6.2.0 +Date: 2026-07-29 19:00:12 UTC +SHA: 51a63a9ad17755d02a549bf2fc095150dff172ef