feat(release): attach C consumer bundles to tagged releases #325

Merged
jqueuniet merged 2 commits from chore/c-dev-bundle into main 2026-09-05 08:20:39 +02:00
Owner

dm2-ffi has no binary distribution today: a C consumer has to clone the
workspace and run cargo, which is exactly the toolchain a prebuilt library
exists to avoid. This attaches two bundles to tagged releases.

Contents

dm2-ffi-<ver>-x86_64-linux-gnu.tar.gz and dm2-ffi-<ver>-x86_64-windows-gnu.zip,
each with:

include/dm2_tools.h      the committed cbindgen header
lib/libdm2_ffi.so        (Linux)
lib/dm2_ffi.dll          (Windows)
lib/libdm2_ffi.dll.a     (Windows: the mingw import library)
README.md  LICENSE-MIT  LICENSE-APACHE

The README is in there deliberately — it carries the Dm2Buffer ownership
contract, which is the part a C caller has to get right and the part the header
alone doesn't spell out.

No new jobs

The Windows DLL is already cross-built for the wheel, and the Linux library
piggybacks on the manylinux job. That placement is the point: glibc there is
2.28, and objdump -T on the result shows GLIBC_2.28 as its highest
requirement, so it loads on RHEL 8, Debian 10 and Ubuntu 18.10 upward. Built in
rust:1-trixie it would demand 2.41 and be useless to most people.

Why no static archive

libdm2_ffi.a is 30-40 MB depending on target, and including it takes the
compressed Linux bundle from 0.8 MB to 9.5 MB — an elevenfold increase to
duplicate code the shared library already provides. Anyone linking statically
can run cargo build -p dm2-ffi --release. Measured, not assumed:

libdm2_ffi.so    2,323,000 -> 2,268,040   (strip --strip-debug)
libdm2_ffi.a    39,570,678 -> 31,483,574
gzipped bundle, shared + static:  9,530,792
gzipped bundle, shared only:        827,905

Verification

Both packaging steps were run verbatim in their real images —
docker.io/rust:1-trixie for Windows, quay.io/pypa/manylinux_2_28_x86_64 for
Linux — producing a 3.4 MB zip and a 0.8 MB tarball with the layouts above.

MSVC consumers need to generate a .lib from the DLL or load it at runtime;
mingw's import library links directly. macOS and aarch64 remain unbuilt, the
same gap the wheels have.

`dm2-ffi` has no binary distribution today: a C consumer has to clone the workspace and run cargo, which is exactly the toolchain a prebuilt library exists to avoid. This attaches two bundles to tagged releases. ## Contents `dm2-ffi-<ver>-x86_64-linux-gnu.tar.gz` and `dm2-ffi-<ver>-x86_64-windows-gnu.zip`, each with: ``` include/dm2_tools.h the committed cbindgen header lib/libdm2_ffi.so (Linux) lib/dm2_ffi.dll (Windows) lib/libdm2_ffi.dll.a (Windows: the mingw import library) README.md LICENSE-MIT LICENSE-APACHE ``` The README is in there deliberately — it carries the `Dm2Buffer` ownership contract, which is the part a C caller has to get right and the part the header alone doesn't spell out. ## No new jobs The Windows DLL is already cross-built for the wheel, and the Linux library piggybacks on the manylinux job. That placement is the point: glibc there is 2.28, and `objdump -T` on the result shows `GLIBC_2.28` as its highest requirement, so it loads on RHEL 8, Debian 10 and Ubuntu 18.10 upward. Built in `rust:1-trixie` it would demand 2.41 and be useless to most people. ## Why no static archive `libdm2_ffi.a` is 30-40 MB depending on target, and including it takes the compressed Linux bundle from 0.8 MB to 9.5 MB — an elevenfold increase to duplicate code the shared library already provides. Anyone linking statically can run `cargo build -p dm2-ffi --release`. Measured, not assumed: ``` libdm2_ffi.so 2,323,000 -> 2,268,040 (strip --strip-debug) libdm2_ffi.a 39,570,678 -> 31,483,574 gzipped bundle, shared + static: 9,530,792 gzipped bundle, shared only: 827,905 ``` ## Verification Both packaging steps were run verbatim in their real images — `docker.io/rust:1-trixie` for Windows, `quay.io/pypa/manylinux_2_28_x86_64` for Linux — producing a 3.4 MB zip and a 0.8 MB tarball with the layouts above. MSVC consumers need to generate a `.lib` from the DLL or load it at runtime; mingw's import library links directly. macOS and aarch64 remain unbuilt, the same gap the wheels have.
feat(release): attach C consumer bundles to tagged releases
Some checks failed
CI / msrv (1.90) (pull_request) Successful in 41s
CI / audit (pull_request) Successful in 20s
CI / python bindings (3.11) (pull_request) Has been cancelled
CI / stable (pull_request) Has been cancelled
9a366befef
`dm2-ffi` had no binary distribution: a C consumer had to clone the
workspace and run cargo, which is the toolchain the prebuilt library exists
to avoid. Releases now carry `dm2-ffi-<ver>-x86_64-linux-gnu.tar.gz` and
`dm2-ffi-<ver>-x86_64-windows-gnu.zip`, each holding `include/dm2_tools.h`,
the shared library, and the crate README beside both licenses. The README is
in there because it documents the `Dm2Buffer` ownership contract — the part a
caller has to get right, and the part the header alone does not spell out.

Neither bundle needs a new job. The Windows DLL is already cross-built for
the wheel, and the Linux library is built in the manylinux job, where glibc
is 2.28: `objdump -T` on the result shows GLIBC_2.28 as its highest
requirement, so it loads on RHEL 8, Debian 10 and Ubuntu 18.10 upward. Built
in rust:1-trixie it would have demanded 2.41.

The static archive is deliberately excluded. `libdm2_ffi.a` is 30-40 MB and
takes the compressed Linux bundle from 0.8 MB to 9.5 MB, duplicating code the
shared library already provides; static linkers can build it themselves.

macOS and aarch64 stay unbuilt, the same gap the wheels have.
docs(release): clarify that the manylinux glibc baseline is a floor
All checks were successful
CI / audit (pull_request) Successful in 19s
CI / msrv (1.90) (push) Successful in 44s
CI / audit (push) Successful in 24s
CI / python bindings (3.11) (push) Successful in 37s
CI / msrv (1.90) (pull_request) Successful in 39s
CI / stable (pull_request) Successful in 1m42s
CI / python bindings (3.11) (pull_request) Successful in 46s
CI / stable (push) Successful in 1m36s
9022102f48
The C bundle note read as though the build targeted Debian 10 and Ubuntu
18.10, which are EOL. glibc 2.28 is a minimum: the library loads on anything
at or above it, meaning every current distribution, with RHEL 8 and its
rebuilds the oldest still-supported systems covered. Raising the floor would
only drop those, and manylinux_2_34 and _2_39 are both ALPHA upstream.
jqueuniet deleted branch chore/c-dev-bundle 2026-09-05 08:20:39 +02:00
Sign in to join this conversation.
No reviewers
No milestone
No project
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
jqueuniet/dm2-tools!325
No description provided.