fix(patches): force RcppParallel to use its bundled oneTBB #146
Loading…
Reference in a new issue
No description provided.
Delete branch "fix/rcppparallel-force-bundled-tbb"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Why
RcppParallelbinaries built on ubuntu 22.04 still recordNEEDED libtbb.so.12and cannotdyn.loadwithout the distro TBB, although #145 landed the link-order patch and build-env-images droppedTBB_INC/TBB_LIBthe same morning.The link-order fix does not survive a build image that exports those variables, and the published images still do:
.crow/images.yamlin build-env-images triggers oncron/manualonly, so every image in the registry is still the 2026-07-21 build.With
TBB_LIBset,configure.Rnever reaches the bundled-oneTBB branch at all,install.libs.RfillsRcppParallel/libwith absolute symlinks into the image's library dir, and the plain-Lfrom #145 just points at the system TBB instead of the bundled one.Nothing on the pipeline side can undo this: R reads
~/.Renvironafter the process environment, so neither a Crowenvironment:block nor the registryenvfield wins.Rather than couple correctness to image freshness for a third round-trip, the patch now forces the bundled TBB itself.
Changes
local/patches/RcppParallel/bundled-tbb-link-order.patch->local/patches/RcppParallel/force-bundled-tbb.patch.Keeps the
-Wl,-L->-Llink-order hunk (the bundled branch has the same problem when a distro libtbb is installed) and adds an opt-out,BINCRAFT_ALLOW_SYSTEM_TBB=TRUE, for the ambientTBB_ROOT/TBB_LIB/TBB_INC.configure.Rbuilds the bundled TBB and then segfaults R on the post-install load test:tools/config/configure.R: branch selection.src/install.libs.R:R CMD INSTALLruns it outside thetbbrule insrc/Makevarsthat passes the configured values, so at install time it still sees the image environment.R/tbb.RtbbLibraryPath(): run time..onLoad()woulddyn.loadthe system TBB into the global scope next to the bundled one thatRcppParallel.soneeds - two copies of the same symbols, hence the segfault.R/tbb.RtbbCxxFlags()/tbbLdFlags(): otherwise dependents such asrstanget the system TBB handed back to them.local/patches/registry.json: new patch path and areasondescribing both failure modes.Verification
Built through
bincraft:::prepare_patched_repo()on the current, unfixed images (all three still exportTBB_INC/TBB_LIB), with bincraft v5.0.1, i.e. what CI deploys:NEEDEDRcppParallel/liblibtbb*moved awaybuild-env-ubuntu:jammylibtbb.so$ORIGIN/../liblibtbb.so.2, 5.0 MBbuild-env-redhat:9libtbb.so$ORIGIN/../liblibtbb.so.2, 5.1 MBbuild-env-alpine:3.24libtbb.so$ORIGIN/../liblibtbb.so.2, 4.7 MBFor contrast, the same jammy build without this change:
With
TBB_LIBstill exported,RcppParallel::tbbLibraryPath()resolves to the package's ownlib, andCxxFlags()emits the package's ownincludeplus-DTBB_INTERFACE_NEW- not/usr/include/oneapi.Behaviour change
Published
RcppParallelbinaries carry their own oneTBB on every platform, whichever image version CI pulls. The patch content changed, so the patched-binary cache key changes with it and no stale entry is reused.The build-env-images fix is still worth rolling out (those images also carry the broken el8
uvrand uvr 0.4.1), but RcppParallel no longer waits on it.Follow-up, not in this PR
The binaries already in B2 are the broken ones; they need a rebuild, and a Bunny
/purgedoes not evict Perma-Cache.