pat-s
7aa6db3135The link-order fix alone does not survive a build image that exports TBB_INC/TBB_LIB. RcppParallel's configure.R then never reaches the bundled branch at all: it links the image's TBB, install.libs.R fills RcppParallel/lib with absolute symlinks into the image's library dir, and the published binary records NEEDED libtbb.so.12 (libtbb.so.2 for the classic Intel TBB on el8/el9), so it cannot dyn.load on a consumer machine without that exact library. build-env-images dropped those variables, but its images are rebuilt only by cron or a manual run, and R reads ~/.Renviron after the process environment, so nothing on the pipeline side can override them in the meantime. Patch the package to ignore an ambient TBB_ROOT/TBB_LIB/TBB_INC instead of relying on the image being clean, in all four places that read them: configure.R (branch selection), install.libs.R (which R CMD INSTALL runs outside the src/Makevars rule that passes the configured values), and R/tbb.R at run time -- .onLoad() would otherwise dyn.load a second, unrelated TBB next to the bundled one, which segfaults R on load, and RcppParallelLibs()/CxxFlags() would hand the system TBB to dependents such as rstan. BINCRAFT_ALLOW_SYSTEM_TBB=TRUE restores the upstream behaviour. Keep the link-order hunk: the bundled branch passes its build dir as '-Wl,-L', which gcc still places after its own search dirs. Verified on the current (pre-fix) build-env images, which still export TBB_INC/TBB_LIB -- ubuntu jammy, redhat 9 and alpine 3.24: NEEDED libtbb.so, rpath $ORIGIN/../lib, real libtbb.so.2 in RcppParallel/lib, and the package loads with every system libtbb moved away. Without the patch on jammy the same build yields NEEDED libtbb.so.12 and fails to load; with the configure-only patch it builds the bundled TBB but segfaults on the post-install load test.
22 lines
2.6 KiB
JSON
22 lines
2.6 KiB
JSON
[
|
|
{
|
|
"package": "RcppParallel",
|
|
"versions": ">=6.0.0",
|
|
"platforms": ["*"],
|
|
"env": {},
|
|
"configure_args": [],
|
|
"makevars": {},
|
|
"patch": "RcppParallel/force-bundled-tbb.patch",
|
|
"reason": "RcppParallel 6.x bundles oneTBB 2022 and builds it with cmake on every platform we ship, so the system-TBB workaround needed for 5.x is gone, but two things still steer the build back to a system TBB. (1) Ambient TBB_ROOT/TBB_LIB/TBB_INC: several build images still export these (build-env-images dropped them, but the images are rebuilt only by cron/manual runs, so a stale image keeps them), and R reads ~/.Renviron *after* the process environment, so no pipeline-side env override can undo it. configure.R then takes the system-TBB branch, install.libs.R symlinks the image's libraries into RcppParallel/lib as absolute paths, and the binary records NEEDED libtbb.so.12 (libtbb.so.2 for the classic Intel TBB on el8/el9) -- it cannot dyn.load on a consumer machine without that exact TBB. Both files are patched to ignore those variables (opt out with BINCRAFT_ALLOW_SYSTEM_TBB=TRUE); install.libs.R needs it separately because R CMD INSTALL runs it outside the src/Makevars rule that passes the configured values. (2) Link order: the bundled branch passes its build dir as '-Wl,-Ltbb/build/lib_release', and gcc expands its own search dirs (/usr/lib64, /usr/lib/<triplet>) into '-L' options ahead of anything forwarded with '-Wl,', so '-ltbb' would still resolve to a distro TBB when one is installed; a plain '-L' puts the bundled dir first. Verified on the current build-env-ubuntu:jammy image (which still exports TBB_INC/TBB_LIB): NEEDED libtbb.so, RUNPATH $ORIGIN/../lib, real libtbb.so.2 in RcppParallel/lib, and the package loads with every system libtbb moved away."
|
|
},
|
|
{
|
|
"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."
|
|
}
|
|
]
|