RcppParallel 6.x rewrote its build: src/Makevars.in no longer has the `USE_TBB=Linux` block the registry patch edited, so the patch could never apply and every build logged "Patch for RcppParallel did not apply cleanly". The workaround it implemented is also obsolete. 6.x bundles oneTBB 2022 and builds it with cmake, which works on musl and with g++ 8-15, so there is no longer a reason to link a system TBB -- and linking one publishes a binary that needs a TBB the consumer does not have. What is still broken upstream is the link order. configure.R names the TBB directory with `-Wl,-L`, and gcc expands its own search dirs into `-L` options ahead of anything forwarded verbatim with `-Wl,`, so on a build host with a distro TBB installed `-ltbb` resolves to that library and RcppParallel.so records its SONAME instead of the bundled `libtbb.so`. The new patch passes a plain `-L` instead. Verified on alpine 3.24, redhat 8 and ubuntu noble: RcppParallel gets NEEDED libtbb.so with RPATH $ORIGIN/../lib and loads with every system libtbb moved away, and rstan 2.32.7 compiles and loads against it with no makevars override -- RcppParallel::CxxFlags() already emits -DTBB_INTERFACE_NEW -- so the rstan entry is dropped too. Summary: - replace RcppParallel/system-tbb.patch with bundled-tbb-link-order.patch - scope the RcppParallel entry to >=6.0.0 and widen its platforms to "*" - drop the rstan entry, made redundant by the bundled oneTBB - exclude local/patches/*.patch from the whitespace-mutating hooks, which rewrote context lines in every diff
22 lines
2 KiB
JSON
22 lines
2 KiB
JSON
[
|
|
{
|
|
"package": "RcppParallel",
|
|
"versions": ">=6.0.0",
|
|
"platforms": ["*"],
|
|
"env": {},
|
|
"configure_args": [],
|
|
"makevars": {},
|
|
"patch": "RcppParallel/bundled-tbb-link-order.patch",
|
|
"reason": "RcppParallel 6.x bundles oneTBB 2022 and builds it with cmake, which works on musl and g++ 8-15, so the system-TBB workaround needed for 5.x is gone. What remains broken is the link order: configure.R passes the TBB directory as '-Wl,-L', and gcc expands its own search dirs (/usr/lib64, /usr/lib/<triplet>) into '-L' options ahead of anything forwarded with '-Wl,'. On a build host with a distro TBB installed, '-ltbb' therefore resolves to the system library and RcppParallel.so records its SONAME (libtbb.so.12, or libtbb.so.2 for the classic Intel TBB on el8/el9) instead of the bundled 'libtbb.so'. The published binary then loads the system TBB rather than the copy in RcppParallel/lib and fails to dyn.load on a consumer machine without one, the same way fs did with libuv. Passing a plain '-L' puts the bundled build dir ahead of gcc's defaults; verified on alpine 3.24, el8 and ubuntu noble to produce NEEDED libtbb.so + RPATH $ORIGIN/../lib, loading with every system libtbb removed."
|
|
},
|
|
{
|
|
"package": "fs",
|
|
"versions": "*",
|
|
"platforms": ["*"],
|
|
"env": {},
|
|
"configure_args": [],
|
|
"makevars": {},
|
|
"patch": "fs/force-vendored-libuv.patch",
|
|
"reason": "fs 2.x configure links system libuv whenever pkg-config finds libuv-devel (installed as a build-time sysreq), producing an fs.so with NEEDED libuv.so.1. That binary fails to dyn.load on consumer machines lacking runtime libuv, because install.packages/renv do not install SystemRequirements (only pak does, and only in the build container). The patch short-circuits configure to copy src/Makevars.vendor and build the bundled static libuv (needs cmake) so the binary is self-contained on every platform. An env/pkg-config override was tried first but the rebuilt binary still linked libuv.so.1, so a source patch is used instead."
|
|
}
|
|
]
|