Prebuilt libdatadog binaries packaged for the .NET tracer (dd-trace-dotnet).
A thin packaging layer over upstream libdatadog. Ships only the FFI components the .NET tracer needs — fewer features → smaller binaries → independent release cadence from upstream.
- Rust 1.91.1 or newer (CI pins to 1.91.1 to match libdatadog's MSRV)
- Git
- PowerShell on Windows; Bash + Docker (with buildx and QEMU for aarch64 Linux builds) elsewhere
# Linux GNU x64
./build.sh --platform x86_64-unknown-linux-gnu --clean
# macOS arm64
./build.sh --platform aarch64-apple-darwin --clean
# Windows. -FileVersion is this repo's release (major.minor.patch), embedded
# as the DLL FileVersion. Omit it for a local build that isn't a release.
./build.ps1 -Platform x64-windows -Clean -FileVersion 1.3.5Output lands in output/libdatadog-<platform>/.
To upgrade the upstream libdatadog version, edit the LIBDATADOG_VERSION file (e.g. 32.0.0 — no v prefix). This is the upstream libdatadog version, distinct from libdatadog-dotnet's own release tag (e.g. v1.3.5) that dd-trace-dotnet pins. The chosen version must be API-compatible with dd-trace-dotnet's native profiler C++ (it calls libdatadog's profiling FFI); otherwise the tracer's C++ build fails on missing identifiers like ddog_prof_SampleType. It's a coordinated change — bump + release here, then the tracer adopts the new release and builds against its profiling headers in the same rollout.
Built with the comma-separated feature set the .NET tracer needs (see build.ps1 / workflow inputs):
profiling,crashtracker,symbolizer,library-config
These are the builder-crate feature flags upstream libdatadog exposes — names map to the underlying cargo features inside libdatadog. Upstream's default release additionally enables telemetry, data-pipeline, log, ddsketch, and ffe; we omit them, saving binary size. (data-pipeline and log were dropped once dd-trace-dotnet removed the libdatadog-based trace exporter and its logger — DataDog/dd-trace-dotnet#8703.)
We install libdatadog's own release binary (from its builder crate) at the pinned tag, then let it produce the package:
cargo install \
--git https://github.com/DataDog/libdatadog \
--tag "v${LIBDATADOG_VERSION}" \
--bin release \
--no-default-features \
--features "<feature-list>" \
builder
release --out <package-dir> --target <triple> [--file-version <major.minor.patch>]
The builder handles the FFI cargo build, header generation (cbindgen + dedup), library stripping, and packaging.
Windows FileVersion: --file-version is the libdatadog-dotnet release (1.3.5 from tag v1.3.5), not LIBDATADOG_VERSION. The builder forwards it as LIBDATADOG_PACKAGE_VERSION and embeds it as the DLL FileVersion — the field Windows Installer compares when deciding whether to replace the file on upgrade. ProductVersion stays the upstream libdatadog version, so that pin is still recoverable from the shipped DLL. The flag does nothing on non-Windows targets. The Release workflow passes it automatically; omit it and FileVersion falls back to the upstream libdatadog version.
Windows quirk: the builder produces a flat lib/datadog_profiling.{dll,lib,pdb} layout, but dd-trace-dotnet's vcpkg portfile expects the legacy release/{dynamic,static} + debug/{dynamic,static} tree with _ffi-suffixed filenames. build.ps1 runs the builder twice (release + debug) and reassembles that layout from cargo's raw target/ output. The VERSIONINFO resource is embedded during that cargo build, so the reassembled DLL keeps the FileVersion set by --file-version.
Linux GNU builds target GLIBC 2.17 (CentOS 7 baseline) so the resulting binaries run on older enterprise distros:
x86_64-unknown-linux-gnu— built in a CentOS 7 container (cross-rs/x86_64-unknown-linux-gnu:main-centos) with devtoolset-10 GCC.aarch64-unknown-linux-gnu— built natively under QEMUlinux/arm64inquay.io/pypa/manylinux2014_aarch64(the only CentOS 7 aarch64 image with devtoolset). aarch64-musl follows the same QEMU pattern usingalpine:3.18+ rustup.
macOS and Windows builds run natively on the appropriate GitHub-hosted runner.
Manual dispatch: Actions → Release → Run workflow. The workflow builds all 8 platforms, creates a git tag, and publishes a GitHub release with checksums.
Prerequisites: authentication is via DataDog's octo-sts (keyless OIDC — no stored secret). The workflow mints a short-lived token with DataDog/dd-octo-sts-action, governed by the trust policy in .github/chainguard/self.release.sts.yaml. The octo-sts app must be installed on the repo and on the ref-creation ruleset's bypass list (the default GITHUB_TOKEN is blocked from creating tag refs). Releases are dispatched from main. Nothing to rotate.
Inputs:
| Input | Default | Notes |
|---|---|---|
version_increment |
patch |
patch / minor / major — ignored if release_version is set |
release_version |
(empty) | Manual override, e.g. v1.4.0 |
The upstream libdatadog version isn't a workflow input — it's pinned in the LIBDATADOG_VERSION file at the time of the release commit. The workflow resolves this repo's own release tag first and passes it to the Windows build as --file-version, so the DLL FileVersion matches the release (for example 1.4.0) rather than LIBDATADOG_VERSION.
For CI runs without publishing a release, use the Build workflow (auto-triggered on every PR and push to main).
Published as GitHub Release assets:
| Platform | Asset |
|---|---|
| Windows x64 | libdatadog-x64-windows.zip |
| Windows x86 | libdatadog-x86-windows.zip |
| Linux x64 (glibc) | libdatadog-x86_64-unknown-linux-gnu.tar.gz |
| Linux aarch64 (glibc) | libdatadog-aarch64-unknown-linux-gnu.tar.gz |
| Linux x64 (musl/Alpine) | libdatadog-x86_64-alpine-linux-musl.tar.gz |
| Linux aarch64 (musl/Alpine) | libdatadog-aarch64-alpine-linux-musl.tar.gz |
| macOS x64 (Intel) | libdatadog-x86_64-apple-darwin.tar.gz |
| macOS arm64 (Apple Silicon) | libdatadog-aarch64-apple-darwin.tar.gz |
Each release body includes SHA256 + SHA512 checksums.
For security vulnerabilities, see SECURITY.md.
Apache 2.0 — see LICENSE. Packages bundle the upstream LICENSE-3rdparty.csv with full third-party license texts.