fix(patches): force fs to build vendored static libuv #111

Merged
pat-s merged 1 commit from fix/fs-vendored-libuv into main 2026-07-07 18:12:37 +00:00
Owner

Problem

The fs 2.1.0 binary links system libuv (readelf -d fs.so shows NEEDED libuv.so.1).
fs's configure prefers system libuv whenever pkg-config resolves it, and our build images ship libuv-devel (installed as a pak build-time system requirement), so the resulting binary is dynamically linked against libuv.so.1.

That binary fails to load on any consumer machine without runtime libuv:

unable to load shared object '.../fs/libs/fs.so':
  libuv.so.1: cannot open shared object file: No such file or directory

install.packages()/renv do not install SystemRequirements (only pak does, and only inside the build container), so most consumers hit this.
Older fs 1.6.x always vendored libuv, so only the 2.x binaries regressed.
Reproduced in a clean reg.devxy.io/r/r-alma:4.5-9.

Fix

Add local/patches/fs/force-vendored-libuv.patch, registered for all platforms.
It short-circuits configure to cp -f src/Makevars.vendor src/Makevars; exit 0 before the pkg-config detection, forcing the bundled static libuv build (tools/libuv-v1.52.0.tar.gz, built via cmake).
An env/pkg-config override (PKG_CONFIG_LIBDIR) was tried first but the rebuilt binary still linked libuv.so.1 (the registry env tier does not reach fs's configure step), so a source patch is used instead.

Verification

Built end-to-end inside the real build-env-redhat:9 image (system libuv present):

  • patch fires (Building static libuv (bincraft: forced vendored)),
  • cmake compiles the vendored libuv,
  • resulting fs.so has no libuv.so.1 in NEEDED (only libR, libstdc++, libm, libgcc_s, libc).

Rscript local/validate-patches.R passes (2 entries).
cmake confirmed present in the build-env images.

Follow-up (not in this PR)

  • Rebuild fs 2.1.0 on every affected platform (rhel8/9/10, ubuntu jammy/noble, alpine 3.22/3.23; amd64 + arm64) and purge the CDN binary paths.
  • CDN delivery gap: purge_cdn_cache.sh only purges PACKAGES*, never package binaries, so rebuilt binaries stay masked until their .tar.gz path is purged.
## Problem The `fs` 2.1.0 binary links **system libuv** (`readelf -d fs.so` shows `NEEDED libuv.so.1`). fs's `configure` prefers system libuv whenever `pkg-config` resolves it, and our build images ship `libuv-devel` (installed as a pak build-time system requirement), so the resulting binary is dynamically linked against `libuv.so.1`. That binary fails to load on any consumer machine without runtime libuv: ```text unable to load shared object '.../fs/libs/fs.so': libuv.so.1: cannot open shared object file: No such file or directory ``` `install.packages()`/renv do **not** install `SystemRequirements` (only `pak` does, and only inside the build container), so most consumers hit this. Older fs 1.6.x always vendored libuv, so only the 2.x binaries regressed. Reproduced in a clean `reg.devxy.io/r/r-alma:4.5-9`. ## Fix Add `local/patches/fs/force-vendored-libuv.patch`, registered for all platforms. It short-circuits `configure` to `cp -f src/Makevars.vendor src/Makevars; exit 0` before the pkg-config detection, forcing the bundled static libuv build (`tools/libuv-v1.52.0.tar.gz`, built via cmake). An env/pkg-config override (`PKG_CONFIG_LIBDIR`) was tried first but the rebuilt binary still linked `libuv.so.1` (the registry `env` tier does not reach fs's configure step), so a source patch is used instead. ## Verification Built end-to-end inside the real `build-env-redhat:9` image (system libuv present): - patch fires (`Building static libuv (bincraft: forced vendored)`), - cmake compiles the vendored libuv, - resulting `fs.so` has **no `libuv.so.1`** in `NEEDED` (only libR, libstdc++, libm, libgcc_s, libc). `Rscript local/validate-patches.R` passes (2 entries). cmake confirmed present in the build-env images. ## Follow-up (not in this PR) - Rebuild `fs 2.1.0` on every affected platform (rhel8/9/10, ubuntu jammy/noble, alpine 3.22/3.23; amd64 + arm64) and purge the CDN binary paths. - CDN delivery gap: `purge_cdn_cache.sh` only purges `PACKAGES*`, never package binaries, so rebuilt binaries stay masked until their `.tar.gz` path is purged.
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. Add a
configure patch that short-circuits to the bundled static libuv build (cmake)
so the fs binary is self-contained on every platform.
pat-s merged commit 36d3bc8604 into main 2026-07-07 18:12:37 +00:00
pat-s deleted branch fix/fs-vendored-libuv 2026-07-07 18:12:37 +00:00
Sign in to join this conversation.
No reviewers
No labels
No milestone
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
devxy/build-cran-binaries!111
No description provided.