Release notes from RcppParallel

RcppParallel 6.2.1

2026-08-28T19:12:27Z

Fixed bundled oneTBB builds with recent libc++, which no longer includes
<algorithm> transitively. tbb/concurrent_queue.h uses std::equal but
did not include it, giving "no member named 'equal' in namespace 'std'" when
compiling concurrent_bounded_queue.cpp, as seen on CRAN's clang-trunk
checks. (#280)
Fixed bundled oneTBB builds and downstream compilation with Clang and libc++
when targeting macOS 10.12 or earlier, where C++17 aligned allocation is not
available. (#219)

RcppParallel 6.2.0

2026-07-30T16:56:49Z

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.
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. 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
cmake was fatal everywhere except Windows, where it instead produced a
package with no TBB backend at all -- a silently degraded install that was
easy to end up with and hard to notice. TBB is now always enabled. Rtools has
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
necessary there for the entry points RcppParallel compiles itself, such as
isProcessForkedChild). Packages that previously resolved TBB symbols out of
RcppParallel.dll, or the tbbmalloc API via -lRcppParallel alone, should
rebuild against these flags.
The tbb.dll compatibility stub is gone. It existed to publish the
pre-oneTBB task_scheduler_observer entry point on top of a statically
linked runtime, but because it linked the TBB archives itself it amounted to
a second, independent copy of the oneTBB scheduler living in the same
process. That entry point is now exported by the real tbb.dll, as it
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, #273)
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_<LANG>_COMPILER_LAUNCHER instead of being mistaken for the compiler
itself. (#267)

RcppParallel 6.1.1

2026-07-27T17:33:08Z

Fixed an issue where package installation could fail if cmake was not
available on the PATH, even when it was discoverable at another known
location (e.g. /Applications/CMake.app/Contents/bin/cmake on macOS).
This caused installation failures on CRAN's macOS machines, where cmake
is not on the PATH by default.
Removed vestigial compiler / flag detection code from the configure
script. This code has been unused since the switch to a cmake-driven
build of the bundled oneTBB, and probed R CMD config variables that
are defunct in R (>= 4.6.0).

RcppParallel 6.1.0

2026-07-26T22:05:01Z

RcppParallel now provides isProcessForkedChild() (R) and
RcppParallel::isProcessForkedChild() (C++), which return TRUE when the
current process is a fork() of the process in which RcppParallel was
loaded.
Packages dispatching parallel work from within parallel::mclapply() (or
similar) should consult this and fall back to a serial path, as TBB does
not support use after fork. (#243, #244)
The TBB backend is now enabled by default on musl-based Linux
distributions, such as Alpine Linux. Previously, TBB was only enabled by
default with glibc-based toolchains on Linux. (#231, #263)
The mingw cpuid guard applied to TBB's _machine.h header during
installation is now logged, and a warning is emitted if the header does
not have the expected form and the guard cannot be applied. (#265)
On Linux, the bundled TBB libraries are once again installed with versioned
names (e.g. libtbb.so.2) plus an unversioned libtbb.so symlink, matching
the layout shipped by RcppParallel 5.1.11 and earlier. The oneTBB cmake build
produces only unversioned libraries on Linux, so binaries compiled against
those releases (which recorded a load-time dependency on libtbb.so.2) would
otherwise fail to load after an upgrade with "libtbb.so.2: cannot open shared
object file". (#260)
Fixed linking of downstream packages using the TBB scalable allocator
on Windows, e.g. via RcppArmadillo's ARMA_USE_TBB_ALLOC. RcppParallel
now links the whole Rtools tbbmalloc archive into RcppParallel.dll
and re-exports its API, so that scalable_malloc, scalable_free, and
friends can be resolved by packages linking with -lRcppParallel. (#262)
Fixed installation on Windows toolchains providing an older (non-oneTBB)
copy of TBB, e.g. Rtools42: the tbb stub library is now built by
re-exporting the static TBB library, rather than wrapping the oneTBB
runtime (which is unavailable there). In addition, stale stub build
artifacts from a different toolchain are no longer reused. (#258)
Fixed installation on Windows systems whose Rtools does not provide TBB
(R < 4.2.0): configure no longer requires cmake there, and the tbb stub
library is no longer built when the TBB backend is disabled. (#257)
RcppParallel now reports which TBB headers and libraries are installed
with the package, and from where, during package installation. In
addition, setting the VERBOSE environment variable to a value other
than 0 enables diagnostics describing how TBB libraries are resolved
and loaded when the package is loaded. (#256, #259)
On Windows, RcppParallel once again loads its compatibility stub library
(tbb.dll) when the package is loaded. Packages linking with -ltbb
(e.g. via StanHeaders) record a load-time dependency on tbb.dll, which
can only be resolved if RcppParallel has already loaded it; with
RcppParallel 6.0.0, such packages would fail to load with "LoadLibrary
failure: The specified module could not be found". (#249, #250)
The TBB headers installed with RcppParallel (whether from Rtools or from
the bundled copy of oneTBB) now guard against GCC's <cpuid.h> being
included before <intrin.h> on Windows (mingw). Previously, translation
units including <cpuid.h> before any TBB header would fail to compile,
as the __cpuid macro from <cpuid.h> conflicts with the __cpuid()
function declared by mingw's <intrin.h>. (#248, #253)
When building the bundled copy of oneTBB, RcppParallel no longer searches
for hwloc, and so no longer tries to build the optional 'tbbbind' library.
This fixes build failures on machines where a static hwloc library is
discoverable via pkg-config, as on the CRAN macOS machines. (#247)
On macOS, the bundled copy of oneTBB is now built with
__TBB_RESUMABLE_TASKS_USE_THREADS, avoiding use of the deprecated
ucontext APIs (getcontext, swapcontext, makecontext). (#247)

RcppParallel 6.0.0

2026-07-23T17:02:20Z

RcppParallel no longer includes tbb headers as part of the RcppParallel/TBB.h
header, and instead only exposes its TBB-specific APIs for parallel work.
RcppParallel now bundles oneTBB 2022.0.0. Note that the TBB ABI has changed;
packages which depend on RcppParallel may need to be rebuilt.
On Windows, RcppParallel now uses the copy of TBB provided by Rtools.
If TBB is not available, RcppParallel will use only the fallback 'tinythread'
implementation. In practice, this implies that RcppParallel will now only
provide a TBB backend with R (>= 4.2.0).
Fixed builds under wasm/webR. (#237; @andrjohns)
Fixed compilation with clang-19 on Windows aarch64. (#235, #236; @andrjohns)
Fixed TBB library lookup on Windows, and removed the obsolete
TBB_USE_GCC_BUILTINS flag for Windows ARM64. TBB is statically linked
on Windows, so the package no longer tries to load TBB libraries there
at load time. (#241; @andrjohns)